From a83ccae5a1e0899d78720762503f6c233d77ca2e Mon Sep 17 00:00:00 2001 From: Dhruv Soni Date: Thu, 19 Feb 2026 09:19:49 +0530 Subject: [PATCH] Revert "RHDEVDOCS-6360: Reviews for External secrets stores" --- _topic_maps/_topic_map.yml | 2 - modules/op-csi-secrets.adoc | 190 ------------------ ...g-secrets-from-external-secret-stores.adoc | 18 -- 3 files changed, 210 deletions(-) delete mode 100644 modules/op-csi-secrets.adoc delete mode 100644 secure/using-secrets-from-external-secret-stores.adoc diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml index 75184a0c81a2..901e659ae747 100644 --- a/_topic_maps/_topic_map.yml +++ b/_topic_maps/_topic_map.yml @@ -117,8 +117,6 @@ Topics: File: securing-webhooks-with-event-listeners - Name: Authenticating pipelines with repositories using secrets File: authenticating-pipelines-repos-using-secrets -- Name: Using secrets from external secret stores - File: using-secrets-from-external-secret-stores - Name: Unprivileged building of container images using Buildah File: unprivileged-building-of-container-images-using-buildah - Name: Using buildah-ns tekton task diff --git a/modules/op-csi-secrets.adoc b/modules/op-csi-secrets.adoc deleted file mode 100644 index 4ce769517481..000000000000 --- a/modules/op-csi-secrets.adoc +++ /dev/null @@ -1,190 +0,0 @@ -// This module is included in the following assembly: -// -// * secure/using-csi-secrets.adoc - -:_mod-docs-content-type: PROCEDURE -[id="consuming-secrets-csi_{context}"] -= Consuming secrets from external stores using the Secrets Store CSI Driver - -[role="_abstract"] -To use secrets from an external secret store that has a Container Storage Interface (CSI) provider, such as HashiCorp Vault, you can configure {pipelines-shortname} to consume these secrets using the Secrets Store CSI Driver. - -.Prerequisites - -* You installed the Secrets Store CSI Driver. For information about installing the CSI Driver, see the link:https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/storage/using-container-storage-interface-csi#persistent-storage-csi-secrets-store[Secrets Store CSI Driver] in the {OCP} documentation. - -* You installed the CSI provider for your external secret store. For information about installing HashiCorp Vault, including its CSI provider, on {OCP}, see link:https://developer.hashicorp.com/vault/docs/deploy/kubernetes/csi/installation[Install the Vault CSI provider] in the Hashicorp documentation. -+ -[NOTE] -==== -To use an instance of HashiCorp Vault running outside your {OCP} cluster, you must provide the address to that instance in the Helm configuration when installing the CSI Provider. For information about providing an external Vault address, see link:https://developer.hashicorp.com/vault/docs/deploy/kubernetes/helm/configuration#externalvaultaddr[Configuration] in the Hashicorp documentation. -==== - -* You configured authentication with the secret store for an {OCP} service account, for example, `pipeline-sa`. For information about configuring Kubernetes authentication with HashiCorp Vault, see link:https://developer.hashicorp.com/vault/docs/auth/kubernetes[Kubernetes auth method] in the HashiCorp documentation. -+ -[NOTE] -==== -You must create the service account in the namespace in which you create pipelines and other Custom Resources (CRs) for {pipelines-shortname}. -==== - -* Ensure that the Secrets Store CSI Driver service account has the required cluster-wide permissions to create service account tokens in all relevant namespaces. Without these permissions, pods will fail to start and you may encounter the following error: -+ -[source,terminal] ----- -User "system:serviceaccount:csi-driver:secrets-store-csi-driver" cannot create resource "serviceaccounts/token" in API group "" in the namespace "tekton-vault" ----- - -.Procedure - -. To allow the CSI driver to mount secrets volumes, configure the namespace to allow privileged pod security: -+ -[source,terminal] ----- -$ oc label namespace tekton-vault pod-security.kubernetes.io/enforce=privileged ----- - -. In the namespace in which you create pipelines, for example, `tekton-vault`, create a `Role` resource that allows `get`, `list`, and `watch` operations for the `secrets` resource. -+ -[source,yaml] ----- -apiVersion: rbac.authorization.k8s.io/v1 -kind: Role -metadata: - name: pipeline-role - namespace: tekton-vault -rules: -- apiGroups: [""] - resources: ["secrets"] - verbs: ["get", "list", "watch"] ----- - -. Create a `RoleBinding` resource that binds the `pipeline-role` role to the service account which you configured for authentication with the secret store, for example, `pipeline-sa`. -+ -[source,yaml] ----- -apiVersion: rbac.authorization.k8s.io/v1 -kind: RoleBinding -metadata: - name: pipeline-role-binding - namespace: tekton-vault -roleRef: - apiGroup: rbac.authorization.k8s.io - kind: Role - name: pipeline-role -subjects: -- kind: ServiceAccount - name: pipeline-sa - namespace: tekton-vault ----- - -. Create a `SecretProviderClass` CR that defines the secrets that your pipeline or task consumes and the mount path and filename (key) for each of these secrets. -+ -[source,yaml] ----- -apiVersion: secrets-store.csi.x-k8s.io/v1 -kind: SecretProviderClass -metadata: - name: vault-secret - namespace: tekton-vault -spec: - provider: vault - parameters: - vaultAddress: "http://vault.vault:8200" - vaultSkipTLSVerify: "true" - roleName: "my-role" - objects: | - - objectName: "demo-secret" - secretPath: "secret/data/my-secret" - secretKey: "username" - - objectName: "demo-secret-pass" - secretPath: "secret/data/my-secret" - secretKey: "password" ----- -+ -[WARNING] -==== -The `vaultAddress` parameter used in this example uses `http` and `vaultSkipTLSVerify`: `"true"` only for demonstration purposes. For production use, configure Vault with a secure `https` endpoint and do not skip TLS verification. -==== - -. In the definition of the task that consumes the secrets, define and mount a volume that uses the CSI secrets store driver and specifies the name of the `SecretProviderClass` CR. To minimise security exposure of secrets, mount them in the definition of a task and not of an entire pipeline. -+ -[source,yaml] ----- -apiVersion: tekton.dev/v1 -kind: Task -metadata: - name: secret-task - namespace: tekton-vault -spec: - steps: - - name: use-secret - image: registry.access.redhat.com/ubi8/ubi-minimal:latest - script: | - #!/bin/sh - echo "Reading secrets from mounted volume..." - echo "Username: $(cat /mnt/secrets-store/demo-secret)" - echo "Password: $(cat /mnt/secrets-store/demo-secret-pass)" - volumeMounts: - - name: secrets-store-inline - mountPath: "/mnt/secrets-store" - readOnly: true - volumes: - - name: secrets-store-inline - csi: - driver: secrets-store.csi.k8s.io - readOnly: true - volumeAttributes: - secretProviderClass: "vault-secret" ----- -+ -[NOTE] -==== -* The mount path that you specify in the pipeline or task definition overrides the path that you specify in the `SecretProviderClass` CR. - -* This example provides secrets for demonstration purposes only. In production environment, do not log secrets as they are visible in pod logs. -==== - -. In the `PipelineRun` or `TaskRun` CR, assign the service account that is authenticated with the secret store to the task: - -** If you create a `PipelineRun` CR, use the `taskRunSpecs` section to assign the service account to the particular task. Do not assign the service account to the entire pipeline. -+ -[source,yaml] ----- -apiVersion: tekton.dev/v1 -kind: Pipeline -metadata: - name: vault-secret-pipeline - namespace: tekton-vault -spec: - tasks: - - name: read-secret - taskRef: - name: secret-task ---- -apiVersion: tekton.dev/v1 -kind: PipelineRun -metadata: - name: vault-secret-pipeline-run - namespace: tekton-vault -spec: - pipelineRef: - name: vault-secret-pipeline - taskRunSpecs: - - pipelineTaskName: read-secret - serviceAccountName: pipeline-sa ----- - -** If you create a `TaskRun` CR, use the `serviceAccountName` setting to assign the service account. -+ -[source,yaml] ----- -apiVersion: tekton.dev/v1 -kind: TaskRun -metadata: - name: vault-secret-task-run - namespace: tekton-vault -spec: - taskRef: - name: secret-task - serviceAccountName: pipeline-sa ----- diff --git a/secure/using-secrets-from-external-secret-stores.adoc b/secure/using-secrets-from-external-secret-stores.adoc deleted file mode 100644 index a71fc9f20acb..000000000000 --- a/secure/using-secrets-from-external-secret-stores.adoc +++ /dev/null @@ -1,18 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -include::_attributes/common-attributes.adoc[] -[id="using-secrets-from-external-secret-stores"] -= Using secrets from external secret stores -:context: using-secrets-from-external-secret-stores - -toc::[] - -[role="_abstract"] -You can configure pipelines to consume secrets from external secret stores by using the Secrets Store CSI Driver. - -include::modules/op-csi-secrets.adoc[leveloffset=+1] - -[role="_additional-resources"] -[id="additional-resources_{context}"] -== Additional resources - -link:https://secrets-store-csi-driver.sigs.k8s.io/getting-started/installation.html[Install the Secrets Store CSI Driver]