|
| 1 | +# Vault resources for monitoring |
| 2 | + |
| 3 | +This folder contains the manifests for the Kubernetes objects needed by the Vault Secrets Operator to reach the CERN Vault instances and authenticate on behalf of monitoring workloads. |
| 4 | + |
| 5 | +The manifests are meant to be applied to the same cluster where the operator runs. |
| 6 | + |
| 7 | +This documentation and setup refers specifically to the deployment of the VSO integration of Vault into Kubernetes. For a comprehensive comparison between the different methods and their benefits, see [the official Vault@CERN documentation](https://vault.docs.cern.ch/docs/integration/comparison/), and for documentation about how to set up each of the different approaches for integration, [this other section of the documentation](https://vault.docs.cern.ch/docs/integration/). |
| 8 | + |
| 9 | +If you have any questions about setting up Vault within your infrastructure after going through this documentation (and the official one linked above), feel free to contact us for help, or to send a message in the official [Vault Mattermost channel](https://mattermost.web.cern.ch/it-dep/channels/vault). |
| 10 | + |
| 11 | +## Prerequisites |
| 12 | + |
| 13 | +- Access to the Vault cluster (`woger-vault.cern.ch` for test environment or `vault-it.cern.ch` prod). You can get it by [creating a SNOW ticket to CERN IT Vault team](https://cern.service-now.com/service-portal?id=sc_cat_item&name=Configuration-Management-Incident&se=Configuration-Management) (it says the ticket is for reporting a Configuration Management issue but they do not have a specific SNOW space at the moment). |
| 14 | +- Keep in mind that everything deployed in this folder is done in a blank namespace specifically created for Vault resources. This is not mandatory but it is still highly recommended. The namespace used in this documenation and in the manifest is `vault-secrets-operator`. |
| 15 | +- Proper CA Certificate bundle for the Vault auth resource setup. In this case we have deployed a secret using the following command: |
| 16 | + |
| 17 | +```bash |
| 18 | +kubectl create secret generic vault-ca-cert --from-file=ca.crt=./etc/pki/tls/certs/ca-bundle.crt -n vault-secrets-operator |
| 19 | +``` |
| 20 | + |
| 21 | +## Customise the manifests |
| 22 | + |
| 23 | +1. Update `vault-connection.yaml`: |
| 24 | + - Set `spec.address` to the Vault endpoint you want to target. |
| 25 | + - Adjust `spec.caCertSecretRef` if the CA secret name differs. |
| 26 | +2. Update `vault-auth.yaml`: |
| 27 | + - Update the `mount` field with the path to the secret engine provided for you by the Vault team. |
| 28 | + - Make sure that `role`, and `allowedNamespaces` match the Vault auth method and Kubernetes namespaces you intend to allow. |
| 29 | +3. Review `vault-service-account.yaml`: |
| 30 | + - Ensure the `namespace` value align with where the operator runs. |
| 31 | + |
| 32 | +## Resource purpose and flow |
| 33 | + |
| 34 | +### `vault-service-account.yaml` |
| 35 | + |
| 36 | +- **ServiceAccount** `vault-auth` lets the operator authenticate to Kubernetes and receive tokens scoped specifically for Vault access. |
| 37 | + |
| 38 | +- **ClusterRole** `vault-token-reviewer` grants permission to request service account tokens and inspect pods/secrets, which Vault needs to validate Kubernetes JWTs. |
| 39 | + |
| 40 | +- **ClusterRoleBinding** ties the ServiceAccount to the ClusterRole so the operator can perform token reviews. |
| 41 | + |
| 42 | +### `vault-connection.yaml` |
| 43 | + |
| 44 | +- Defines how the operator reaches Vault (endpoint URL, TLS, CA bundle). Without this object the operator cannot establish a session with Vault. |
| 45 | + |
| 46 | +### `vault-auth.yaml` |
| 47 | + |
| 48 | +- Points at the connection, declares the `kubernetes` auth method, and references the ServiceAccount/role. This resource links Kubernetes identities to Vault roles and specifies which namespaces may use the auth configuration. |
| 49 | + |
| 50 | +Together these manifests ensure the operator can present a Kubernetes service account token, Vault can validate it via the token reviewer permissions, and the operator can fetch secrets from the configured Vault mount. |
| 51 | + |
| 52 | +## Deploy the resources |
| 53 | + |
| 54 | +```bash |
| 55 | +kubectl apply -f /root/projects/CMSKubernetes/kubernetes/monitoring/vault/vault-service-account.yaml |
| 56 | +kubectl apply -f /root/projects/CMSKubernetes/kubernetes/monitoring/vault/vault-connection.yaml |
| 57 | +kubectl apply -f /root/projects/CMSKubernetes/kubernetes/monitoring/vault/vault-auth.yaml |
| 58 | +``` |
| 59 | + |
| 60 | +Apply them in that order so the ServiceAccount and RBAC exist before the Vault |
| 61 | +connection and auth references. |
| 62 | + |
| 63 | +## Verification |
| 64 | + |
| 65 | +- Confirm the ServiceAccount secret was created: |
| 66 | + |
| 67 | + ```bash |
| 68 | + kubectl -n vault-secrets-operator get sa vault-auth -o yaml |
| 69 | + ``` |
| 70 | + |
| 71 | +- Check the operator logs to ensure it establishes the connection and auth: |
| 72 | + |
| 73 | + ```bash |
| 74 | + kubectl -n vault-secrets-operator logs deploy/vault-secrets-operator |
| 75 | + ``` |
0 commit comments