Skip to content

Commit 46c72ca

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

5 files changed

+265
-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-installing-and-configuring-vault-to-store-a-secret.adoc

Lines changed: 104 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,104 @@
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+
. Initializing 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+
. Unsealing 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+
. Logging 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+
. Enabling 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+
Explanation for the Parameters:
100+
`issuer`: The Kubernetes token issuer URL.
101+
`token_reviewer_jwt`: A JSON Web Token (JWT) that Vault uses to call the Kubernetes TokenReview API and validate service account tokens.
102+
`kubernetes_host`: The URL that Vault uses to communicate with the Kubernetes API server.
103+
`kubernetes_ca_cert`: The CA certificate that Vault uses for secure communication with the Kubernetes API server.
104+

‎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+
* The {gitops-title} Operator is installed on your 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+
----

‎modules/gitops-managing-secrets-using-sscsid-with-gitops-overview.adoc

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -34,6 +34,7 @@ The following secrets store providers are available for use with the Secrets Sto
3434
* AWS Secrets Manager
3535
* AWS Systems Manager Parameter Store
3636
* Microsoft Azure Key Vault
37+
* HashiCorp Vault
3738

3839
As an example, consider that you are using AWS Secrets Manager as your secrets store provider with the SSCSI Driver Operator. The following example shows the directory structure in {gitops-shortname} repository that is ready to use the secrets from AWS Secrets Manager:
3940

‎securing_openshift_gitops/managing-secrets-securely-using-sscsid-with-gitops.adoc

Lines changed: 11 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -28,10 +28,19 @@ include::modules/gitops-managing-secrets-using-sscsid-with-gitops-overview.adoc[
2828
include::modules/gitops-storing-aws-secret-manager-resources-in-gitops-repository.adoc[leveloffset=+1]
2929

3030
// Configuring SSCSI driver to mount secrets from AWS Secrets Manager
31-
include::modules/gitops-configuring-sscsi-driver-to-mount-secrets-from-aws-secrets-manager.adoc[leveloffset=+1]
31+
include::modules/gitops-configuring-sscsi-driver-to-mount-secrets-from-aws-secrets-manager.adoc[leveloffset=+2]
3232

3333
// Configuring GitOps managed resources to use mounted secrets
34-
include::modules/gitops-configuring-gitops-managed-resources-to-use-mounted-secrets.adoc[leveloffset=+1]
34+
include::modules/gitops-configuring-gitops-managed-resources-to-use-mounted-secrets.adoc[leveloffset=+2]
35+
36+
// Configure HashiCorp Vault as a secrets provider on OpenShift with GitOps
37+
include::modules/gitops-configure-hashicorp-vault-as-a-secrets-provider-on-openshift-with-gitops.adoc[leveloffset=+1]
38+
39+
// Installing the Vault CSI Provider using GitOps
40+
include::modules/gitops-installing-the-vault-csi-provider-using-gitops.adoc[leveloffset=+2]
41+
42+
// Installing and configuring Vault to store a Secret
43+
include::modules/gitops-installing-and-configuring-vault-to-store-a-secret.adoc[leveloffset=+2]
3544

3645
[role="_additional-resources"]
3746
[id="additional-resources_{context}"]

0 commit comments

Comments
 (0)