The B.C. government Vault Secrets Management tool, based on the HashiCorp Vault product, provides a tool for securely accessing secrets. A secret is anything that you want to tightly control access to, such as API keys, passwords, or certificates. Vault provides a unified interface to any secret, while providing tight access control and recording a detailed audit log.
You can also still use Kubernetes Secrets backed by ETCD. It is recommended that Kubernetes Secrets be reserved for non-secrets (e.g. environment variables).
Non-secrets may be stored in Vault if desired.
- Features and functions
- Eligibility and prerequisites
- How to request access
- How do I get help?
- What does it cost?
- Support roles, processes, communications (platform operations)
- Service delivery
Users of this service gain access to the following:
Arbitrary key/value secrets can be stored in Vault. Vault encrypts these secrets prior to writing them to persistent storage, so gaining access to the raw storage isn't enough to access your secrets.
Vault can generate secrets on-demand for some systems, such as Azure or SQL databases. For example, when an application needs to access a PostgreSQL database, it asks Vault for credentials, and Vault will generate a keypair with valid permissions on demand. After creating these dynamic secrets, Vault will also automatically revoke them after the lease is up. Learn more about the PostgreSQL database secrets engine.
Vault can encrypt and decrypt data without storing it. This allows security teams to define encryption parameters and developers to store encrypted data in a location such as SQL without having to design their own encryption methods.
All secrets in Vault have a lease associated with them. At the end of the lease, Vault will automatically revoke that secret. Clients are able to renew leases via built-in renew APIs.
Vault has built-in support for secret revocation. Vault can revoke not only single secrets, but a tree of secrets, for example all secrets read by a specific user, or all secrets of a particular type. Revocation assists in key rolling as well as locking down systems in the case of an intrusion.
Your team is provisioned a Vault service account for each environment (dev, test, prod, and tools) through the automation backing the Platform Services Registry. Each ProjectSet created in the registry can have up to two technical contacts associated with it. These technical contacts are given write access to Vault and can manage secrets within a ProjectSet's two mount points (nonprod, prod).
You don’t need to request access to Vault. If you have a project set, you have at least one technical contact who can access Vault through the CLI or UI, and you have a Kubernetes Service Account associated with your project set's Vault Mount Points in each namespace environment. (dev, test, prod, and tools).
Service Accounts take the form of
Here is the step-by-step guide on integrating Vault into your application on OpenShift.
The Vault Secrets Management tool is deployed in a high-availability configuration within the highly available Gold clusters in OpenShift. This service is available 24/7 with best effort to restart failed systems.
The best source of help is the vibrant community of product teams using Vault for their projects.
You can find this highly talented and knowledgeable group in the #devops-vault channel on Rocket.Chat.
For help beyond this contact one of the Vault administrators via the #devops-sos channel on Rocket.Chat.
There is no charge for this service.
The team supporting this service administers the Vault application and its supporting services.
Vault interfaces with Kubernetes services to provide authentication via service accounts.
Rocket.Chat is the primary mode of communication. Specifically, the #devops-vault channel should be used to engage the community for best practices, configuration and troubleshooting questions.
For cluster wide service notifications that may impact Vault monitor, use the #devops-alerts channels in Rocket.Chat.
For teams without Rocket.Chat access or to escalate a question or concern, contact us by email at PlatformServicesTeam@gov.bc.ca.
There is no onboarding to use Vault.
As part of project onboarding, Kubernetes service accounts are generated for your project namespaces and these service accounts are used for integrating team applications with Vault.
Product teams can choose to use Vault or ETCD backed Kubernetes Secrets, but it is recommended that Vault be used for secrets.
Any changes to the Vault Secrets Management tool will be communicated via #devops-vault and #internal-devops-vault Rocket.Chat channels. For major service update, the Vault Operations team will reach out to product owners for notice.
Vault Secrets Management improvements including system upgrades, feature integration and issue fixing. The Vault Operations team will be conducting the operation on a scheduled time, with advanced notice in the #devops-vault Rocket.Chat channel. If disruption or downtime is expected during service improvement, the team will discuss on maintenance time in the channel to minimize effects.
To be determined.
An STRA for Vault has been completed by the Platform Services team.