Skip to content

Commit 21559ff

Browse files
Dhruv-Soni11Dhruv-Soni11
committed
RHDEVDOCS-6450: Content creation for Vault documentation
1 parent b84d7be commit 21559ff

8 files changed

+508
-2
lines changed

‎modules/gitops-configure-hashicorp-vault-as-a-secrets-provider-on-openshift-with-gitops.adoc

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
// Module is included in the following assemblies:
2+
//
3+
// * securing_openshift_gitops/managing-secrets-securely-using-sscsid-with-gitops.adoc
4+
5+
:_mod-docs-content-type: CONCEPT
6+
[id="gitops-configure-hashicorp-vault-as-a-secrets-provider-on-openshift-with-gitops_{context}"]
7+
= Configure HashiCorp Vault as a secrets provider on OpenShift with GitOps
8+
9+
You can configure HashiCorp Vault as a secrets provider by using the Secrets Store CSI Driver Operator on the {OCP}. When combined with GitOps workflows managed by Argo CD, this setup enables you to securely retrieve secrets from Vault and inject it into your applications running on OpenShift.
10+
11+
Structure the {gitops-shortname} repository and configure the Vault CSI provider to integrate with the Secrets Store CSI Driver in {OCP}.
12+
13+
The following sample {gitops-shortname} repository layout is used for integrating Vault with your application.
14+
15+
.Example directory structure in {gitops-shortname} repository
16+
----
17+
├── config
18+
│   ├── argocd # <1>
19+
│   │   ├── vault-secret-provider-app.yaml
20+
│   │   ├── ...
21+
│── environments
22+
│   ├── dev
23+
│   │   ├── apps
24+
│   │   │   ├── demo-app
25+
│   │   │   ├── manifest # <2>
26+
│   │   │      | ├── secretProviderClass.yaml
27+
│   │   │      | ├── serviceAccount.yaml
28+
│   │   │      | ├── deployment.yaml
29+
│   │   │   ├── argocd # <3>
30+
│   │   │      ├── demo-app.yaml
31+
----
32+
<1> `config/argocd/` - Stores Argo CD Application definitions for cluster-wide tools like the Vault CSI provider.
33+
<2> `environments/<env>/apps/<app-name>/manifest/`: Contains Kubernetes manifests specific to an application in a particular environment.
34+
<3> `environments/<env>/apps/<app-name>/argocd/`: Contains the Argo CD Application definition that deploys the application and its resources.

‎modules/gitops-configuring-gitops-managed-resources-to-use-vault-mounted-secrets.adoc

Lines changed: 129 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,129 @@
1+
// Module is included in the following assemblies:
2+
//
3+
// * securing_openshift_gitops/managing-secrets-securely-using-sscsid-with-gitops.adoc
4+
5+
:_mod-docs-content-type: PROCEDURE
6+
[id="gitops-configuring-gitops-managed-resources-to-use-vault-mounted-secrets_{context}"]
7+
= Configuring GitOps managed resources to use Vault-mounted secrets
8+
9+
Securely inject secrets from HashiCorp Vault into GitOps-managed Kubernetes workloads using the Secrets Store CSI driver and Vault provider. The secrets are mounted as files in the pod's filesystem, allowing applications to access the data without storing it in Kubernetes Secret objects.
10+
11+
.Procedure
12+
13+
. Creating the `SecretProviderClass`.
14+
15+
.. Create a `SecretProviderClass` resource in the application's manifest directory for example, `environments/dev/apps/demo-app/manifest/secretProviderClass.yaml`. This resource defines how the Secrets Store CSI driver retrieves secrets from Vault.
16+
+
17+
.Example `vault-secret-provider-app.yaml` file
18+
[source,yaml]
19+
----
20+
apiVersion: secrets-store.csi.x-k8s.io/v1
21+
kind: SecretProviderClass
22+
metadata:
23+
name: demo-app-creds
24+
namespace: demo-app
25+
spec:
26+
provider: vault #<1>
27+
parameters:
28+
vaultAddress: http://vault.vault-csi-provider:8200 # <name>.<namespace>:port #<2>
29+
roleName: app #<3>
30+
objects: | #<4>
31+
- objectName: "demoAppUsername"
32+
secretPath: "secret/demo/config"
33+
secretKey: "username"
34+
- objectName: "demoAppPassword"
35+
secretPath: "secret/demo/config"
36+
secretKey: "password"
37+
----
38+
<1> `<provider: vault>` - Specifies the name of the HashiCorp Vault.
39+
<2> `<vaultAddress>` - Specifies the network address of the Vault server. Adjust this based on your Vault setup, such as, in-cluster service or an external URL.
40+
<3> `<roleName>` - Specifies the Vault Kubernetes authentication role used by the application Service Account.
41+
Describes an array that defines which secrets to retrieve and how to map them to file names.
42+
<4> `<objects>` - Specifies an array that defines which secrets to retrieve and how to map them to file names. The `secretPath` for KV v2 includes `/data/`.
43+
44+
. Create an Application, such as, `ServiceAccount`.
45+
46+
.. Create a Kubernetes `ServiceAccount` for the application workload. The `ServiceAccount` name must match the `bound_service_account_names` value defined in the Vault Kubernetes authentication role. Store the manifest in the GitOps repository, for example, `environments/dev/apps/demo-app/manifest/serviceAccount.yaml`.
47+
+
48+
.Example `ServiceAccount.yaml` file
49+
[source,yaml]
50+
----
51+
apiVersion: v1
52+
kind: ServiceAccount
53+
metadata:
54+
name: demo-app-sa
55+
namespace: demo-app
56+
----
57+
58+
. Create the Application deployment:
59+
60+
.. Modify the application's deployment to use the designated `ServiceAccount` and mount secrets using the CSI volume. Store the updated manifest in the GitOps repository, for example, `environments/dev/apps/demo-app/manifest/deployment.yaml`:
61+
+
62+
.Example `deployment.yaml` file
63+
[source,yaml]
64+
----
65+
apiVersion: apps/v1
66+
kind: Deployment
67+
metadata:
68+
name: app
69+
namespace: demo-app
70+
labels:
71+
app: demo
72+
spec:
73+
replicas: 1
74+
selector:
75+
matchLabels:
76+
app: demo
77+
template:
78+
metadata:
79+
labels:
80+
app: demo
81+
spec:
82+
serviceAccountName: demo-app-sa # <1>
83+
containers:
84+
- name: app
85+
image: nginxinc/nginx-unprivileged:latest
86+
volumeMounts: # <2>
87+
- name: vault-secrets
88+
mountPath: /mnt/secrets-store
89+
readOnly: true
90+
volumes: # <3>
91+
- name: vault-secrets
92+
csi:
93+
driver: secrets-store.csi.k8s.io
94+
readOnly: true
95+
volumeAttributes:
96+
secretProviderClass: demo-app-creds
97+
----
98+
<1> `serviceAccountName` - Assigns the Kubernetes `ServiceAccount` name, for example, `demo-app-sa`, used by the application pod. This `ServiceAccount` is fundamental for authenticating with HashiCorp Vault, as it is linked to a Vault role that grants permissions to retrieve the necessary secrets.
99+
<2> `volumeMounts` - Mounts the vault-secrets volume into the container at the `/mnt/secrets-store` directory.
100+
<3> `volumes` - Defines the vault-secrets volume using the `secrets-store.csi.k8s.io` driver and references the `demo-app-creds` `SecretProviderClass`.
101+
102+
. Define the Argo CD application for the workload:
103+
104+
.. Define an Argo CD application resource to deploy application components such as `ServiceAccount`, `SecretProviderClass`, and `Deployment` from the GitOps repository. Store the Argo CD manifest in a directory location, such as, `environments/dev/apps/demo-app/argocd/demo-app.yaml`.
105+
+
106+
.Example `demo-app.yaml` file
107+
[source,yaml]
108+
----
109+
apiVersion: argoproj.io/v1alpha1
110+
kind: Application
111+
metadata:
112+
name: demo-app
113+
namespace: openshift-gitops
114+
spec:
115+
project: default
116+
source:
117+
repoURL: https://your-git-repo-url.git
118+
targetRevision: HEAD
119+
path: environments/dev/apps/demo-app/manifest
120+
destination:
121+
server: https://kubernetes.default.svc
122+
namespace: demo-app
123+
syncPolicy:
124+
automated:
125+
prune: true
126+
selfHeal: true
127+
syncOptions:
128+
- CreateNamespace=true
129+
----

‎modules/gitops-installing-and-configuring-vault-to-store-a-secret.adoc

Lines changed: 105 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,105 @@
1+
// Module is included in the following assemblies:
2+
//
3+
// * securing_openshift_gitops/managing-secrets-securely-using-sscsid-with-gitops.adoc
4+
5+
:_mod-docs-content-type: PROCEDURE
6+
[id="gitops-installing-and-configuring-vault-to-store-a-secret_{context}"]
7+
= Installing the Vault CSI Provider using {gitops-shortname}
8+
9+
After deploying Vault using Argo CD and applying the necessary SCC permissions and DaemonSet patches, initialize Vault, unseal it, and configure Kubernetes authentication to enable secure secret storage and access.
10+
11+
.Procedure
12+
13+
. Access the Vault Pod.
14+
15+
.. If Vault is running within your {OCP} cluster, for example, as the `vault-0` pod in the `vault-csi-provider` namespace, run the following command to access the Vault CLI inside the pod:
16+
+
17+
[source,terminal]
18+
----
19+
$ oc exec -it vault-0 -n vault-csi-provider -- /bin/sh
20+
----
21+
22+
. Initialize Vault.
23+
24+
.. If your Vault instance is not yet initialized, run the following command:
25+
+
26+
[source,terminal]
27+
----
28+
$ vault operator init
29+
----
30+
+
31+
As a result, the following output is displayed.
32+
+
33+
[source,output]
34+
----
35+
5 Unseal Keys - required to unseal the Vault.
36+
Initial Root Token - required to log in and configure Vault.
37+
----
38+
+
39+
[IMPORTANT]
40+
====
41+
Store these credentials securely. At least 3 out of 5 unseal keys are required to unseal Vault. If the keys are lost, access to stored secrets is permanently blocked.
42+
====
43+
44+
. Unseal Vault.
45+
46+
.. Vault starts in a sealed state. Run the following commands to use three of the five Unseal Keys obtained in the earlier step:
47+
+
48+
[source,terminal]
49+
----
50+
$ vault operator unseal <Unseal Key 1>
51+
vault operator unseal <Unseal Key 2>
52+
vault operator unseal <Unseal Key 3>
53+
----
54+
+
55+
Once unsealed, the Vault becomes active and ready for use.
56+
57+
. Log into Vault.
58+
59+
.. To use the root token to log in to Vault, run the following command:
60+
+
61+
[source,terminal]
62+
----
63+
$ vault login <Initial Root Token>
64+
----
65+
+
66+
This provides administrator access to enable and configure secret engines and authentication methods.
67+
68+
. Enable Kubernetes Authentication in Vault.
69+
70+
.. Run the following command to enable Kubernetes authentication in Vault.
71+
+
72+
[source,terminal]
73+
----
74+
$ vault auth enable kubernetes
75+
----
76+
+
77+
This allows Kubernetes workloads, for example, pods, to authenticate with Vault using their service accounts.
78+
79+
. Configure Kubernetes authentication method in Vault.
80+
81+
.. To configure Vault for communicating with the Kubernetes API, run the following command:
82+
+
83+
[source,terminal]
84+
----
85+
$ vault write auth/kubernetes/config \
86+
issuer="https://kubernetes.default.svc" \
87+
token_reviewer_jwt="$(cat/var/run/secrets/kubernetes.io/serviceaccount/token)" \
88+
kubernetes_host="https://${KUBERNETES_PORT_443_TCP_ADDR}:443" \
89+
kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
90+
----
91+
+
92+
As a result, the following output is displayed.
93+
+
94+
[source,output]
95+
----
96+
Success! Data written to: auth/kubernetes/config
97+
----
98+
+
99+
Where:
100+
+
101+
* `<issuer>` is the name of the Kubernetes token issuer URL.
102+
* `<token_reviewer_jwt>` is a JSON Web Token (JWT) that Vault uses to call the Kubernetes `TokenReview` API and to validate service account tokens.
103+
* `<kubernetes_host>` is the URL that Vault uses to communicate with the Kubernetes API server.
104+
* `<kubernetes_ca_cert>` is the CA certificate that Vault uses for secure communication with the Kubernetes API server.
105+

‎modules/gitops-installing-the-vault-csi-provider-using-gitops.adoc

Lines changed: 115 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,115 @@
1+
// Module is included in the following assemblies:
2+
//
3+
// * securing_openshift_gitops/managing-secrets-securely-using-sscsid-with-gitops.adoc
4+
5+
:_mod-docs-content-type: PROCEDURE
6+
[id="gitops-installing-the-vault-csi-provider-using-gitops_{context}"]
7+
= Installing the Vault CSI Provider using {gitops-shortname}
8+
9+
Install the Vault CSI provider by deploying an Argo CD Application that uses HashiCorp's official Helm chart. This method follows {gitops-shortname} best practices by managing the installation declaratively through a version-controlled Argo CD Application resource.
10+
11+
.Prerequisites
12+
13+
* You are logged in to the OpenShift Container Platform cluster as an administrator.
14+
* You have access to the {OCP} web console.
15+
* The link:https://docs.openshift.com/container-platform/latest/nodes/pods/nodes-pods-secrets-store.html#persistent-storage-csi-secrets-store-driver-install_nodes-pods-secrets-store[SSCSI Driver Operator] is installed on your cluster.
16+
* You installed xref:../installing_gitops/installing-openshift-gitops.adoc#installing-openshift-gitops[{gitops-title}] on your {OCP} cluster.
17+
* You have a {gitops-shortname} repository ready to use the secrets.
18+
19+
.Procedure
20+
21+
. Creating the Argo CD Application resource for the Vault CSI Provider.
22+
23+
.. Create an Argo CD Application resource to deploy the Vault CSI provider. Add this resource to your {gitops-shortname} repository, for example, `config/argocd/vault-secret-provider-app.yaml`:
24+
+
25+
.Example `vault-secret-provider-app.yaml` file
26+
[source,yaml]
27+
----
28+
apiVersion: argoproj.io/v1alpha1
29+
kind: Application
30+
metadata:
31+
name: vault-secret-provider-app
32+
namespace: openshift-gitops
33+
spec:
34+
destination:
35+
namespace: vault-csi-provider
36+
server: https://kubernetes.default.svc
37+
project: default
38+
source:
39+
repoURL: https://helm.releases.hashicorp.com
40+
chart: vault
41+
targetRevision: 0.30.0
42+
helm:
43+
releaseName: vault
44+
values: |
45+
csi:
46+
enabled: true
47+
server:
48+
enabled: true
49+
dataStorage:
50+
enabled: false
51+
injector:
52+
enabled: false
53+
syncPolicy:
54+
automated:
55+
prune: true
56+
selfHeal: true
57+
syncOptions:
58+
- CreateNamespace=true
59+
ignoreDifferences:
60+
- kind: DaemonSet
61+
group: apps
62+
jsonPointers:
63+
- /spec/template/spec/containers/0/securityContext/privileged
64+
65+
----
66+
+
67+
[NOTE]
68+
====
69+
The `server.enabled: true` and `dataStorage.enabled: false` settings in the Helm values deploy a HashiCorp Vault server instance using ephemeral storage. This setup is suitable for development or testing environments. For production, you can enable `dataStorage` with a persistent volume (PV) or use an external Vault cluster and set `server.enabled` to `false`. If a Vault server is already deployed, you can set `server.enabled` to `false`.
70+
====
71+
72+
. Apply the `vault-secret-provider-app.yaml` file from the {gitops-shortname} repository to your cluster:
73+
+
74+
[source,terminal]
75+
----
76+
$ oc apply -f vault-secret-provider-app.yaml
77+
----
78+
+
79+
After deploying the Vault CSI provider, the `vault-csi-provider` DaemonSet may fail to run. This issue occurs because {OCP} restricts privileged containers by default. In addition, the Vault CSI provider and the Secrets Store CSI Driver require access to `hostPath` mounts, which {OCP} blocks unless the pods run as privileged.
80+
81+
.. To resolve permission issues in {OCP}:
82+
83+
... Patch the `vault-csi-provider` DaemonSet to run its containers as privileged:
84+
+
85+
[source,terminal]
86+
----
87+
$ oc patch daemonset vault-csi-provider -n vault-csi-provider --type=json --patch='[{"op":"add","path":"/spec/template/spec/containers/0/securityContext","value":{"privileged":true}}]
88+
----
89+
90+
... Grant the Secrets Store CSI Driver service account access to the privileged Security Context Constraints (SCC) in {OCP}.
91+
+
92+
[source,terminal]
93+
----
94+
$ oc adm policy add-scc-to-user privileged \ system:serviceaccount:openshift-cluster-csi-drivers:secrets-store-csi-driver-operator
95+
----
96+
97+
... Grant the Vault CSI Provider service account access to the privileged Security Context Constraints (SCC) in {OCP}.
98+
+
99+
[source,terminal]
100+
----
101+
$ oc adm policy add-scc-to-user privileged \
102+
system:serviceaccount:vault-csi-provider:vault-csi-provider
103+
----
104+
+
105+
[NOTE]
106+
====
107+
If `server.enabled` is set to `true` in the Helm chart, the Vault server pods run with specific user IDs (UIDs) or group IDs (GIDs) that {OCP} blocks by default.
108+
====
109+
110+
... Grant the Vault server service account the required Security Context Constraints (SCC) permissions.
111+
+
112+
[source,terminal]
113+
----
114+
$ oc adm policy add-scc-to-user anyuid system:serviceaccount:vault-csi-provider:vault
115+
----

0 commit comments

Comments
 (0)