218 lines
No EOL
10 KiB
Markdown
218 lines
No EOL
10 KiB
Markdown
# OpenBao
|
||
|
||
## Outline 📋
|
||
- [🧐 What is it?](#-what-is-it)
|
||
- [🤔 Why do I want it?](#-why-do-i-want-it)
|
||
- [🤿 Diving deeper](#-diving-deeper)
|
||
- [🔨 How to use it](#-how-to-use-it)
|
||
- [🔗 References](#-references)
|
||
|
||
## 🧐 What is it?
|
||
|
||
OpenBao is a **secret management tool** embedded into your application stack. It can handle the creation, storage, and management of secrets, ensuring they remain secure. For seamless integration across multiple Kubernetes applications, OpenBao works with the [Kubernetes External Secrets Operator](https://external-secrets.io/latest/), which converts OpenBao’s secrets into Kubernetes secrets.
|
||
|
||
## 🤔 Why do I want it?
|
||
|
||
### Secure Secrets Storage
|
||
OpenBao organizes your secrets in one encrypted location, reducing the risk of loss or accidental exposure, such as through a public code push.
|
||
|
||
### Controlled Access
|
||
OpenBao allows you to define rules about who can access which secrets and under what conditions.
|
||
|
||
### Leasing and Revocation
|
||
Secrets with a lease are automatically revoked at the end of their lifespan. Revocation can also be done manually.
|
||
|
||
### Dynamic Secrets
|
||
OpenBao generates short-lived secrets on demand and revokes them automatically when they’re no longer needed.
|
||
|
||
### Encryption as a Service
|
||
OpenBao encrypts and decrypts data without storing it, offering cryptographic functions as a service.
|
||
|
||
### Audit Devices and logs
|
||
Detailed logs track who accessed which secrets and when, providing complete traceability in case of a breach.
|
||
|
||
### Secret Engines
|
||
OpenBao offers diverse ways to manage secrets through various secret engines.
|
||
Learn more about available secret engines [here](#secret-engines-1).
|
||
|
||
## 🤿 Diving deeper
|
||
|
||
### Secure Secrets Storage
|
||
OpenBao validates and authorizes clients (users, machines, applications) using tokens before granting access to secrets or sensitive data.
|
||
|
||
How does gaining access to OpenBao secrets work?
|
||
|
||
|
||
|
||
|
||
|
||
- **Authentication:** Before a human or machine can gain any access, an administrator must configure OpenBao with an auth method. When a client tries to log in to OpenBao, the system checks client’s data against an internal or external (see *Validation* below) system. Once authenticated, Vault generates an **access token** for the client. This token is then used for every action performed in OpenBao.
|
||
|
||
<b style="color:orange">Note: the administrator can provide you with an already generated access token</b>
|
||
|
||
- **Validation:** If trusted third-party credential repositories (e.g., GitHub, LDAP, AppRole) are specified, OpenBao forwards authentication to them.
|
||
- **Authorization:** Vault applies policies based on the authentication method and rules set by the admin to the token that was generated during authentication. Policies provide a declarative way to grant or forbid access to certain **paths** and **operations** in OpenBao.
|
||
- **Access:** The client uses the token for access to secrets, keys, or encryption capabilities, as per the associated policies.
|
||
|
||
If you want to read more about authentication, visit https://openbao.org/docs/concepts/auth/
|
||
|
||
### Controlled Access
|
||
|
||
OpenBao uses policies to manage access to secrets. Policies are basically a **combination of paths and capabilities** (operations) that they allow on these path. Let’s consider this example:
|
||
|
||
```
|
||
path "secret/app1/password" {
|
||
capabilities = ["create", " read ", "list", "delete"]
|
||
}
|
||
|
||
path "secret/app2/* " {
|
||
capabilities = ["read", "list"]
|
||
}
|
||
```
|
||
|
||
This policy permits *creating*, *reading*, *listing*, and *deleting* the password at `secret/app1/`, but only allows *reading* and *listing* **all** resources in `secret/app2/` and its subpaths.
|
||
|
||
[Here's a tutorial how to use it.](#controlled-access-2)
|
||
|
||
For even deeper understanding, go to https://openbao.org/docs/concepts/policies/
|
||
|
||
### Leasing and Revocation
|
||
|
||
To simplify key rolling processes, consumers using OpenBao should regularly verify their subscription status to either renew leases where permitted or request replacements for secrets that need updating.
|
||
In addition to that, a lease can be revoked manually. When this happens, it invalidates that secret immediately and prevents any further renewals. OpenBao 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.
|
||
|
||
For example:
|
||
In the Kubernetes secrets engine, revoking a lease deletes associated Kubernetes service accounts, immeditally rendering their access keys invalid.
|
||
|
||
[Here's a tutorial how to use it.](#leasing-and-revocation-2)
|
||
|
||
### Dynamic Secrets
|
||
OpenBao generates temporary secrets for systems like Kubernetes, AWS, or SQL databases, only when needed. These secrets are revoked automatically after their Time-To-Live expires.
|
||
For example:
|
||
An application requests Kubernetes credentials from OpenBao, which generates a token with specific permissions. The token is automatically revoked after its lease ends.
|
||
|
||
[Here's a tutorial how to use it.](#dynamic-secrets-2)
|
||
|
||
### Encryption as a Service
|
||
|
||
The transit secrets engine handles cryptographic operations on data in transit without storing it. It can encrypt, decrypt, sign, verify, and generate hashes or random bytes.
|
||
|
||
For example:
|
||
Your application sends data to OpenBao for encryption before saving it to a database. OpenBao can then decrypt the data on demand, ensuring security even if the database is compromised.
|
||
|
||
[Here's a tutorial how to use it.](#encryption-as-a-service-2)
|
||
|
||
Here you can read more about the transit secrets engine https://openbao.org/docs/secrets/transit/
|
||
|
||
### Audit devices and logs
|
||
|
||
**Audit devices** are the tool for collecting detailed **logs** of all requests to OpenBao, and their responses. Because every operation with OpenBao is an API request/response, when using a single audit device, the audit log contains every interaction with the OpenBao API, including errors - except for a few paths which do not go via the audit system.
|
||
**Audit log** telemetry on the other hand provides information on the health of your configured audit devices.
|
||
|
||
[Here's a tutorial how to use it.](#audit-devices-and-logs-2)
|
||
|
||
For more information, plese read https://openbao.org/docs/audit/ and https://openbao.org/docs/internals/telemetry/metrics/audit/
|
||
|
||
|
||
### Secret Engines
|
||
|
||
One of the core concepts of OpenBao are secret engines. Think of them as a set of path-based APIs, that can be provided with some set of data, after which they take some action on that data, and they return a result.
|
||
Let’s shortly take a look at all the OpenBao’s secret engines to better understand what they are.
|
||
1. **Key-Value** secret engines – for storing key value pairs
|
||
2. **PKI** (Public Key Infrastructure) secret engine - for certificate management
|
||
3. **SSH** secret engine - for managing SSH credentials
|
||
4. **Transit** secrets engine - for encrypting data without storing it
|
||
5. **Time-based One-Time Passwords** (TOTP) secret engine - for two-factor authentication
|
||
6. **Kubernetes** secrets engine - for seamless integration with containerized applications
|
||
|
||
Here you can find out more about secret engines https://openbao.org/docs/secrets/
|
||
|
||
|
||
## How to set it up?
|
||
|
||
<b style="color:red; background:pink"> Note: This paragraph will be absolete in the future as the functionality will be automated.</b>
|
||
<br>
|
||
<b style="color: orange"> Hint: To be able to use OpenBao it has to be unsealed first. This happens automatically. While unsealing an initial token is being created. To access this token just run the ./getpassword.sh script. </b>
|
||
|
||
The External Secrets Operator needs a kubernetes secret containing the **OpenBao's initial token** (see above) to access its secrets. You can create it with:
|
||
|
||
`kubectl create secret generic vault-token --from-literal=token=<root_token_from_getpassword.sh> -n openbao`
|
||
|
||
To perform any actions in OpenBao you need to authenticate using the following command:
|
||
|
||
`kubectl exec -ti openbao-0 -n openbao -- vault login <root_token_from_getpassword.sh>`
|
||
|
||
For demontrational purposes you can enable a **Key-Value secret engine** on the path **/data** with:
|
||
|
||
`kubectl exec -ti openbao-0 -n openbao -- vault secrets enable -path=data kv`
|
||
|
||
And to add your first secret just run:
|
||
|
||
`kubectl exec -ti openbao-0 -n openbao -- vault kv put data/postgres POSTGRES_USER=admin POSTGRES_PASSWORD=123456`
|
||
|
||
To fetch it as a kubernetes secret you'll need to create an **external-secrets.yaml** file and apply it to the cluster with `kubectl apply -f external-secrets.yaml`
|
||
|
||
```yaml
|
||
|
||
# external-secret.yaml
|
||
apiVersion: external-secrets.io/v1beta1
|
||
kind: ExternalSecret
|
||
metadata:
|
||
name: external-secret
|
||
namespace: openbao
|
||
spec:
|
||
refreshInterval: "15s" #This specifies the time interval at which the ExternalSecret controller will refresh the secrets.
|
||
secretStoreRef: # This references the first file.
|
||
name: bao-backend
|
||
kind: SecretStore
|
||
target: #This specifies the target Kubernetes secret that the ExternalSecret will create.
|
||
name: postgres-secret
|
||
creationPolicy: Owner
|
||
data: # This is an array of secret key-value pairs that the ExternalSecret will retrieve from the Vault secret store and store in the Kubernetes secret.
|
||
- secretKey: POSTGRES_USER #Name of the k8 secret that is being created
|
||
remoteRef: #This is an object that contains the reference to the secret in the Vault secret store.
|
||
key: data/postgres # This specifies the path to the secret in the Vault secret store
|
||
property: POSTGRES_USER #This specifies the name of the secret property to retrieve from the Vault secret.
|
||
- secretKey: POSTGRES_PASSWORD
|
||
remoteRef:
|
||
key: data/postgres
|
||
property: POSTGRES_PASSWORD
|
||
```
|
||
|
||
After that just run `kubectl get externalsecrets -A` to check that there are no problems with synchronization. And to access the secret on your cluster run: `kubectl get secrets -n openbao`
|
||
|
||
|
||
## 🔨 How to use it?
|
||
|
||
### Uneasling
|
||
|
||
(Some theory)
|
||
|
||
`In our stack the unsealing happens automatically. Nothing to be done here.`
|
||
|
||
### Controlled Access
|
||
|
||
`Short tutorial here`
|
||
|
||
### Leasing and Revocation
|
||
|
||
`Short tutorial here`
|
||
|
||
### Dynamic Secrets
|
||
|
||
`Short tutorial here`
|
||
|
||
### Encryption as a Service
|
||
|
||
`Short tutorial here`
|
||
|
||
### Audit Devices and logs
|
||
|
||
`Short tutorial here`
|
||
|
||
## 🔗 References
|
||
|
||
- image: https://openbao.org/docs/concepts/policies/
|
||
- https://openbao.org/docs/what-is-openbao/
|
||
- https://www.vaultproject.io/
|
||
- https://developer.hashicorp.com/vault |