DevFW-CICD/edp-doc
17
0
Fork 1
Code Issues Pull requests 2 Projects Releases Packages Wiki Activity Actions

docs/user-documentation/openbao.md aktualisiert

Browse source
This commit is contained in:
Michal.Wrobel 2025-01-15 15:07:17 +00:00
parent 90de5149ff
commit b67bba5b49
1 changed files with 480 additions and 68 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

538
docs/user-documentation/openbao.md
View file

@ -5,6 +5,7 @@
- [🤔 Why do I want it?](#-why-do-i-want-it)
- [🤿 Diving deeper](#-diving-deeper)
- [🔨 How to use it](#-how-to-use-it)
- [📝 Cheatsheet](#-cheatsheet)
- [🔗 References](#-references)
## 🧐 What is it?
@ -13,31 +14,31 @@ OpenBao is a **secret management tool** embedded into your application stack. It
## 🤔 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.
#### 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. To dive deeper take a look [here 🤿](#secure-secrets-storage-1)
### Controlled Access
OpenBao allows you to define rules about who can access which secrets and under what conditions.
#### Controlled Access
OpenBao allows you to define rules about who can access which secrets and under what conditions. To dive deeper take a look [here 🤿](#controlled-access-1)
### Leasing and Revocation
Secrets with a lease are automatically revoked at the end of their lifespan. Revocation can also be done manually.
#### Leasing and Revocation
Secrets with a lease are automatically revoked at the end of their lifespan. Revocation can also be done manually. To dive deeper take a look [here 🤿](#leasing-and-revocation-1)
### Dynamic Secrets
OpenBao generates short-lived secrets on demand and revokes them automatically when they’re no longer needed.
#### Dynamic Secrets
OpenBao generates short-lived secrets on demand and revokes them automatically when they’re no longer needed. To dive deeper take a look [here 🤿](#dynamic-secrets-1)
### Encryption as a Service
OpenBao encrypts and decrypts data without storing it, offering cryptographic functions as a service.
#### Encrypction as a Service
OpenBao encrypts and decrypts data without storing it, offering cryptographic functions as a service. To dive deeper take a look [here 🤿](#encryption-as-a-service)
### Audit Devices and logs
Detailed logs track who accessed which secrets and when, providing complete traceability in case of a breach.
#### Audit Devices and logs
Detailed logs track who accessed which secrets and when, providing complete traceability in case of a breach. To dive deeper, take a look [here 🤿](#audit-devices-and-logs-1)
### Secret Engines
#### Secret Engines
OpenBao offers diverse ways to manage secrets through various secret engines.
Learn more about available secret engines [here](#secret-engines-1).
To dive deeper take a look [here 🤿](#secret-engines-1).
## 🤿 Diving deeper
### Secure Secrets Storage
#### 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?
@ -46,37 +47,47 @@ 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.
- **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, OpenBao 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>
<b style="color:orange">Note: the administrator can also 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.
- **Authorization:** OpenBao 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/
[Here's a tutorial how to use it 🔨 ](#secret-engines-2)
### Controlled Access
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" {
path "database/postgres" {
capabilities = ["create", " read ", "list", "delete"]
}
path "secret/app2/* " {
path "database/myslq/* " {
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.
This policy permits *creating*, *reading*, *listing*, and *deleting* the secrets at `database/postgres/`, but only allows *reading* and *listing* **all** resources in `database/mysql/` and its subpaths.
[Here's a tutorial how to use it.](#controlled-access-2)
[Here's a tutorial how to use it 🔨 ](#controlled-access-2)
For even deeper understanding, go to https://openbao.org/docs/concepts/policies/
For even deeper understanding, go to https://openbao.org/docs/concepts/policies/ 🔗
### Leasing and Revocation
#### Dynamic Secrets
Dynamic secrets do not exist until read. These secrets are revoked automatically after use. Most of the OpenBao's *secrets engines* are *dynamic secret engines* (more on that later).
For example:
An application requests Kubernetes credentials from OpenBao, which generates a token with specific permissions. The token is automatically revoked after use or its lease end.
[Here's a tutorial how to use it 🔨 ](#dynamic-secrets-2)
#### 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.
@ -84,55 +95,53 @@ In addition to that, a lease can be revoked manually. When this happens, it inva
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)
[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
#### 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's a tutorial how to use it 🔨 ](#enrypction-as-a-service-2)
Here you can read more about the transit secrets engine https://openbao.org/docs/secrets/transit/
Here you can read more about the transit secrets engine https://openbao.org/docs/secrets/transit/ 🔗
### Audit devices and logs
#### 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.
**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)
Types of Audit Devices:
- **File**: Writes audit logs to a local file.
- **Syslog**: Sends audit logs to local syslog agent for centralized logging and analysis.
- **Socket**: Sends audit events to a custom HTTP endpoint for integration with other systems.
For more information, plese read https://openbao.org/docs/audit/ and https://openbao.org/docs/internals/telemetry/metrics/audit/
[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
#### 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
Let’s shortly take a look at a few examples of OpenBao’s secret engines to better understand what they are.
1. **Key-Value** secret engines – for storing key value pairs (with our without secret versioning: kv1/kv2)
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
7. **And many others...**
Here you can find out more about secret engines https://openbao.org/docs/secrets/
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>
<b style="color:red"> Note: This paragraph will be absolete in the future as the functionality will be automated.</b>
<b style="color: orange"> Hint: To be able to use OpenBao it has to be [unsealed](#uneasling) first. This happens automatically. </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:
@ -184,35 +193,438 @@ After that just run `kubectl get externalsecrets -A` to check that there are no
## 🔨 How to use it?
### Uneasling
#### Uneasling
(Some theory)
When an OpenBao server starts, it begins in a sealed state. In this state, OpenBao is configured to know where and how to access the physical storage, but it cannot decrypt any of the stored data because it's lacking the **encryption key**. Unsealing is the process of solving this issue.
`In our stack the unsealing happens automatically. Nothing to be done here.`
<b style="color:orange">Note: In the sealed state no operations are possible exept of unsealing the OpenBao and checking the status of the seal.</b>
### Controlled Access
This **encryption key** is stored together with the OpenBao's secrets, but encrypted with another encryption key, known as the **root key**. The **root key** however is also encrypted, this time by the **unseal key**. The **unseal key** can have the form of an algorith called **[Shamir Secret's Sharing](https://en.wikipedia.org/wiki/Shamir%27s_secret_sharing)** (multiple Key Shares) or might be stored in a **trusted device or service**.
`Short tutorial here`
- **Shamir's Secret Sharing:** The unseal key is split into multiple parts (e.g. five parts), and only a subset (e.g. three parts) is needed to reconstruct it.
- **Trusted Device or Service:** The unseal key can be stored securely in a trusted service, such as Cloud KMS or AWS KMS.
### Leasing and Revocation
Graphical recap:
`Short tutorial here`
![Shamir's Secret Sharing Unseal Key](https://openbao.org/assets/images/openbao-shamir-seal-9ba848ed9f348e03b004fc0cd92af233.png)
### Dynamic Secrets
To learn more, visit: https://openbao.org/docs/concepts/seal/ 🔗
`Short tutorial here`
`In our stack unsealing happens automatically. To access the root token just run: ./getpassword.sh`
### Encryption as a Service
#### Secret Engines
`Short tutorial here`
<b style="color:orange">Note: OpenBao is a fork of [Hashicorp Vault](https://www.hashicorp.com/products/vault). The "bao" keyword is the equivalent of the "vault" keyword and they can be used interchangeably for OpenBao.</b>
### Audit Devices and logs
To use OpenBao, you first need to log in using your root token.
`Short tutorial here`
`kubectl exec -ti openbao-0 -n openbao -- bao login <root_token_from_getpassword.sh>`
Let's enable the first secret engine — the **key-value (KV) secrets engine** without secret versioning - on the path **/database/**.
`kubectl exec -ti openbao-0 -n openbao -- bao secrets enable -path=database kv`
Now, let's add your first secret to the *postgres* and mysql folders in that KV engine path.
```
kubectl exec -ti openbao-0 -n openbao -- bao kv put database/postgres user=postgres password=123456
kubectl exec -ti openbao-0 -n openbao -- bao kv put database/mysql user=admin password=654321
```
This way, we've saved **two** secrets with each two key value pairs in the KV secret engine activated at path */database/*.
To retrieve this secret, use the *get* command with the specific path.
`kubectl exec -ti openbao-0 -n openbao -- bao kv get database/postgres`
or
`kubectl exec -ti openbao-0 -n openbao -- bao kv get database/mysql`
#### Controlled Access
OpenBao allows you to write with **entities**, **authentication method**, or **tokens**. Let's only consider the entities in detail for the understanding puprose and only take a brief look at the the auth methods and tokens.
##### Entities
First, enable the userpass auth method.
`kubectl exec -ti openbao-0 -n openbao -- bao auth enable userpass`
Now let's create the two users, user1 and user2, with two different policies **user1-policy** and **user2-policy**.
```
kubectl exec -ti openbao-0 -n openbao -- bao write auth/userpass/users/user1 password="password1" policies="user1-policy"
kubectl exec -ti openbao-0 -n openbao -- bao write auth/userpass/users/user2 password="password2" policies="user2-policy"
```
###### User 1 Policy
Create a file called `user1-policy.hcl` with the following content:
```
path "database/postgres" {
capabilities = ["create", "read" , "list", "delete"]
}
```
Now let's copy it to the pod running OpenBao with:
`kubectl cp user1-policy.hcl -n openbao openbao-0:/tmp/user1-policy.hcl`
And now apply the hcl file to the **user1-policy** which is already assigned to the **user 1**:
`kubectl exec -ti openbao-0 -n openbao -- bao policy write user1-policy /tmp/user1-policy.hcl`
###### User 2 Policy
Now create another filed called `user2-policy.hcl`.
```
path "database/myslq/* " {
capabilities = ["read", "list"]
}
```
Let's copy it:
`kubectl cp user2-policy.hcl -n openbao openbao-0:/tmp/user2-policy.hcl`
And apply the policy with:
`kubectl exec -ti openbao-0 -n openbao -- bao policy write user2-policy /tmp/user2-policy.hcl`
###### Login
Now let's login as the user 1, with:
`kubectl exec -ti openbao-0 -n openbao -- bao login -method=userpass username=user1 password=password1`
And let's access the `database/postgres` secrets with:
`kubectl exec -ti openbao-0 -n openbao -- bao kv get database/postgres`
Let's delete them and then check if they're really gone:
```
kubectl exec -ti openbao-0 -n openbao -- bao kv delete database/postgres
kubectl exec -ti openbao-0 -n openbao -- bao kv list database/postgres
```
Trying to access the secrets at `database/mysql` should not be possible, since our policy doesn't allow it. Let's confirm that with:
`kubectl exec -ti openbao-0 -n openbao -- bao kv get database/mysql`
You can also try performing these steps accordingly for the **user 2**.
To login back to the root user run: `kubectl exec -ti openbao-0 -n openbao -- bao login <root_token>`
##### Authentication methods
For example:
`kubectl exec -ti openbao-0 -n openbao -- bao write auth/userpass/users/<username> policies=<policy1>,<policy2>`
or
`kubectl exec -ti openbao-0 -n openbao -- bao write auth/aws/role/<role-name> policies=<policy1>,<policy2>`
##### Tokens
For example:
`kubectl exec -ti openbao-0 -n openbao -- bao token create -policy="<policy-name>"`
or for all tokens created in your OpenBao instance:
`kubectl exec -ti openbao-0 -n openbao -- bao write sys/policies/acl/default policy=my-policy`
#### Dynamic Secrets
Until now, we’ve been using the **static Key-Value (KV) Secret Engine** to store credentials. Let’s switch to a **dynamic** one—the **Database Secret Engine**.
To delete the **KV Secrets Engine** at path `/database` run:
`kubectl exec -ti openbao-0 -n openbao -- bao secrets disable database`
To set up the **Database Secret Engine**, we’ll need the following:
- A running **database instance**
- The **dynamic secret engine** itself
- A **database role**
##### Database
First, create a new namespace:
`kubectl create namespace postgres-demo`
Next, define the following **postgres-deployment.yaml** file:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: postgres
namespace: postgres-demo
spec:
replicas: 1
selector:
matchLabels:
app: postgres
template:
metadata:
labels:
app: postgres
spec:
containers:
- name: postgres
image: postgres:15
ports:
- containerPort: 5432
env:
- name: POSTGRES_USER
value: postgres
- name: POSTGRES_PASSWORD
value: password
- name: POSTGRES_DB
value: postgres
volumeMounts:
- name: postgres-data
mountPath: /var/lib/postgresql/data
volumes:
- name: postgres-data
emptyDir: {}
```
Then, define the corresponding **postgres-service.yaml** file:
```
apiVersion: v1
kind: Service
metadata:
name: postgres
namespace: postgres-namespace
spec:
type: ClusterIP
selector:
app: postgres
ports:
- port: 5432
targetPort: 5432
```
Apply both files with:
```
kubectl apply -f postgres-deployment.yaml
kubectl apply -f postgres-service.yaml
```
##### Secret Engine
Enable the **Database Secret Engine** on the default path by running:
`kubectl exec -ti openbao-0 -n openbao -- bao enable database`
<b style="color:orange">Hint: You can explicitly specify a custom path using the `-path="/custom/path"` argument.</b>
Now, configure the secret engine to connect to the PostgreSQL instance and define which roles it will support:
```
kubectl exec -ti openbao-0 -n openbao -- bao write database/config/my-postgres \
plugin_name=postgresql-database-plugin \
connection_url="postgresql://postgres:password@postgres.postgres-demo.svc.cluster.local:5432/postgres?sslmode=disable" \
allowed_roles="readonly, my-postgres-role"
```
In this example:
- The `readonly` role is a default one.
- The `my-postgres-role` is a custom role we’ll define in the next step.
##### Database Role
A OpenBao role is a policy-like configuration that:
1. Tells OpenBao how to create database users.
2. Defines what permissions these users will have in the database.
3. Controls the lifetime (TTL) of the credentials Vault generates.
4. Specifies which Vault clients (e.g., applications or users) are allowed to request credentials.
Let's consider this example:
```
kubectl exec -ti openbao-0 -n openbao -- bao write database/roles/my-postgres-role \
db_name=postgres \
creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}'; GRANT ALL PRIVILEGES ON DATABASE mydatabase TO \"{{name}}\";" \
default_ttl="1h" \
max_ttl="24h"
```
The `my-postgres-role`:
1. Tells OpenBao to create a user with a `{{name}}` and `{{password}}` from the `connection_url` of the [secret engine](#secret-engine) specification - in our example *postgres* and *password*.
2. Defines to `GRANT ALL PRIVILEGES ON DATABASE` to that user.
3. Sets the `default_ttl` to 1 hour and `max_ttl` to 24 hours.
4. As already mentioned - dynamic secrets do not exist until read. Only users with access to the path `database/roles/my-postgres-role` are allowed to get the above specified credentials.
Let's now generate a postgres database credentials with:
`kubectl exec -ti openbao-0 -n openbao -- bao read database/creds/readonly`
or
`kubectl exec -ti openbao-0 -n openbao -- bao read database/creds/my-postgres-role`
#### Leasing and Revocation
##### Leasing
To understand how leasing and revocation work we will need the [Dynamic Secrets Engine](#dynamic-secrets-2) we've set up before.
As we've seen the `bao read` command returns us the secrets lease ID.
To set the Lease Durations for a whole Secrets Engine use:
`kubectl exec -ti openbao-0 -n openbao -- bao write database/config max_ttl=1h default_ttl=30m`
You can also override the lease duration of a single secret with:
`kubectl exec -ti openbao-0 -n openbao -- bao read -ttl=15m database/mysql`
##### Revocation
You can revoke a secret manually using:
`vault lease revoke <lease_id>` for a single secret, or
`vault lease revoke -prefix <database>` for all secrets issued under a specific path.
#### Enrypction as a Service
Enable the **Database Secret Engine** on the default path by running:
`kubectl exec -ti openbao-0 -n openbao -- bao secrets enable transit`
<b style="color:orange">Hint: You can explicitly specify a custom path using the `-path="/custom/path"` argument.</b>
##### Encryption
Create your first encryption key, with:
`kubectl exec -ti openbao-0 -n openbao -- bao write -f transit/keys/my-key`
This creates a AES-256-GCM (by default) encryption key named **my-key** and stores it securely.
To encrypt some data, use:
`kubectl exec -ti openbao-0 -n openbao -- bao write transit/encrypt/my-key plaintext=$(echo -n "hello-world" | base64)`
Explanation:
- `bao write transit/encrypt/my-key` - points to the key we want to use
- `plaintext` - for encryption there are two main types of data: `plaintext` (unencrypted) and `ciphertext` (encrypted)
- `$(echo -n "hello-world" | base64)` - OpenBao expects all data for encryption to be in the Base64 format.
##### Decryption
To decrypt the data, use:
`kubectl exec -ti openbao-0 -n openbao -- bao write transit/decrypt/my-key ciphertext="vault:v1:..."`
Explanation:
- `bao write transit/decrypt/my-key` - notice that this time we're using the `decrypt` part of the path
- `ciphertext` - this time the data we're providing is already encrypted
- `vault:` - indicates that the text has been encrypted by OpenBao
- `v1` - tells OpenBao which version of the key has been used to encrypt the data. This way OpenBao knows how to handle the ciphertext even after key rotation.
You should see `aGVsbG8td29ybGQ=` as the result. To convert it to a readable form, run:
`echo "aGVsbG8td29ybGQ=" | base64 --decode`
For more information visit https://openbao.org/docs/secrets/transit/#setup 🔗
#### Audit Devices and logs
For a **File Audit Device** use:
`bao audit enable file file_path=/var/log/openbao_audit.log`
For a **Syslog Audit Device** use:
`bao audit enable syslog`
And for a **Socket Audit device** run:
`bao audit enable socket address=<address> socket_type=<tcp/udp>`
## 📝 Cheatsheet
All important commands discussed in the tutorials
```
# Login to OpenBao
kubectl exec -ti openbao-0 -n openbao -- bao login <root_token_from_getpassword.sh>
or
kubectl exec -ti openbao-0 -n openbao -- bao login -method=userpass username=user1 password=password1
# Enable Key-Value secrets engine
kubectl exec -ti openbao-0 -n openbao -- bao secrets enable -path=database kv
# Add a secret to the KV engine
kubectl exec -ti openbao-0 -n openbao -- bao kv put database/postgres user=postgres password=123456
# Retrieve a secret from the KV engine
kubectl exec -ti openbao-0 -n openbao -- bao kv get database/postgres
# Enable userpass authentication method
kubectl exec -ti openbao-0 -n openbao -- bao auth enable userpass
# Create a user with specific policies
kubectl exec -ti openbao-0 -n openbao -- bao write auth/userpass/users/user1 password="password1" policies="user1-policy"
# Apply policy for a user
kubectl exec -ti openbao-0 -n openbao -- bao policy write user1-policy /tmp/user1-policy.hcl
# Write a database secret engine configuration
kubectl exec -ti openbao-0 -n openbao -- bao write database/config/my-postgres \
plugin_name=postgresql-database-plugin \
connection_url="postgresql://postgres:password@postgres.postgres-demo.svc.cluster.local:5432/postgres?sslmode=disable" \
allowed_roles="readonly, my-postgres-role"
# Write a database role
kubectl exec -ti openbao-0 -n openbao -- bao write database/roles/my-postgres-role \
db_name=postgres \
creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}'; GRANT ALL PRIVILEGES ON DATABASE mydatabase TO \"{{name}}\";" \
default_ttl="1h" \
max_ttl="24h"
# Generate dynamic credentials
kubectl exec -ti openbao-0 -n openbao -- bao read database/creds/my-postgres-role
# Change lease duration of a secret
kubectl exec -ti openbao-0 -n openbao -- bao read -ttl=15m database/mysql
# Revoke a secret or multiple secrets
vault lease revoke <lease_id>
vault lease revoke -prefix <database>
# Create encryption key
kubectl exec -ti openbao-0 -n openbao -- bao write -f transit/keys/my-key
# Encrypt data
kubectl exec -ti openbao-0 -n openbao -- bao write transit/encrypt/my-key plaintext=$(echo -n "hello-world" | base64)
# Decrypt data
kubectl exec -ti openbao-0 -n openbao -- bao write transit/decrypt/my-key ciphertext="vault:v1:..."
# File audit device
kubectl exec -ti openbao-0 -n openbao -- bao audit enable file file_path=/var/log/openbao_audit.log
# Syslog audit device
kubectl exec -ti openbao-0 -n openbao -- bao audit enable syslog
# Socket audit device
bao audit enable socket address=<address> socket_type=<tcp/udp>
```
## 🔗 References
- image: https://openbao.org/docs/concepts/policies/
- image 1: https://openbao.org/docs/concepts/policies/
- image 2: https://openbao.org/docs/concepts/seal/
- https://openbao.org/docs/what-is-openbao/
- https://openbao.org/docs/secrets/transit/
- https://www.vaultproject.io/
- https://developer.hashicorp.com/vault
- https://developer.hashicorp.com/vault/tutorials/get-started/understand-static-dynamic-secrets#dynamic-secrets