Manage credentials with Tekton and OpenShift on IBM Cloud

Securing a CI/CD workflow involves more than building and deploying code. Cloud-native environments require security policies for every component, from credentials to pipeline tasks. This article explains how to protect secrets, enforce compliance, and build a trusted software supply chain using Tekton Pipelines on Red Hat OpenShift on IBM Cloud. You will learn how to manage Kubernetes Secrets, integrate IBM Cloud Key Protect or Secrets Manager, apply OpenShift security policies, and use Tekton Chains and signing tools to ensure integrity across the pipeline.

Building security into automated workflows

CI/CD pipelines automate builds, tests, deployments, security checks, and even compliance tasks. However, automation increases the risk of security breaches. A single leaked credential or unsigned image can compromise an entire cluster.

When working with Tekton Pipelines on Red Hat OpenShift on IBM Cloud, security must be built into the workflow. Tekton provides modular, Kubernetes-native automation, while OpenShift brings advanced security primitives and trusted supply chain tooling. Combined with IBM Cloud cryptographic services, they enable a hardened CI/CD setup.

This post focuses on practical application, showing examples, YAML snippets, and pipeline patterns.

Architecture overview

The following diagram shows a secure CI/CD workflow:

Developer commits code to Git -------------------------------+
                                                             |
                                                             v
                                                      Tekton Pipeline
                                             +-------------------------------+
                                             | 1. Fetch Source               |
                                             | 2. Build Container            |
                                             | 3. Scan for Vulnerabilities   |
                                             | 4. Sign & Generate SBOM       |
                                             | 5. Enforce Policy Gates       |
                                             +-------------------------------+
                                                             |
                                                             v
                                            Deploy to Red Hat OpenShift on IBM Cloud
                                                             |
                                                             v
                                            Continuous Compliance/Runtime Security

At each step, security is enforced:

• Secrets are injected only when needed.
• Images are scanned and signed.
• Policies block unsafe deployments.
• Clusters verify signatures and provenance.

Managing secrets in Tekton on OpenShift

Protecting sensitive credentials is a fundamental requirement for any production-grade CI/CD pipeline.

Why simple Kubernetes Secrets aren't enough

Imagine your pipeline needs to push an image to IBM Cloud Container Registry. Storing the registry API key in a plain Kubernetes Secret means:

• It is only base64 encoded.
• Multiple pods might access it improperly.
• Anyone with sufficient role-based access control (RBAC) can decode it.
• It persists in the cluster even after the pipeline ends.

This risk is significant for credentials that access production systems.

A better pattern: Short-lived and externally managed secrets

A recommended practice is to:

1. Store credentials in IBM Cloud Key Protect or Secrets Manager.
2. Use the External Secrets Operator to fetch them at runtime.
3. Map secrets only to the Tekton service account.
4. Clean them up automatically when the pipeline completes.

This approach ensures the secret:

• Never resides in Git
• Never persists in the cluster.
• Is rotated automatically at the source.
• Is injected only for the pipeline tasks that require it.

Practical example: Using a container registry API key

Suppose you need a key to push an image. First, you create the secret:

ibmcloud cr token-add --description "ci-cd-pipeline" --readwrite

Store this token in IBM Cloud Secrets Manager under:

prod/cicd/ibmcr-token

Then, define an ExternalSecret to fetch the token into the cluster:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: ibm-cr-credentials
  namespace: cicd
spec:
  refreshInterval: 5m
  secretStoreRef:
    name: ibmcloud-secretstore
    kind: SecretStore
  target:
    name: ibm-cr-secret
  data:
    - secretKey: .dockerconfigjson
      remoteRef:
        key: prod/cicd/ibmcr-token

Finally, bind the secret to the Tekton service account:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: pipeline
  namespace: cicd
imagePullSecrets:
  - name: ibm-cr-secret

The key is retrieved when needed and is not stored permanently.

Enforcing security policies in Tekton Pipelines

Integrating automated policy checks directly into pipeline tasks ensures that security standards are validated early in the build process.

Example: Detecting credential leaks

Developers sometimes (accidentally) commit API keys or passwords to the repository. You can add a pre-build policy check task to detect these credentials:

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: scan-for-secrets
spec:
  steps:
    - name: trufflehog
      image: docker.io/trufflesecurity/trufflehog:latest
      script: |
        trufflehog filesystem /workspace/source || true

To fail the build when secrets are detected, you can use the following script logic:

trufflehog filesystem /workspace/source
if [ $? -ne 0 ]; then
  echo "Secret leak detected!"
  exit 1
fi

Example: Blocking deployment if vulnerabilities exceed a threshold

Suppose your organization doesn't allow deployment of images containing critical Common Vulnerabilities and Exposures (CVEs).

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: cve-policy-check
spec:
  steps:
    - name: scan
      image: registry.access.redhat.com/ubi9/ubi
      script: |
        critical=$(jq '.vulnerabilities.critical' /workspace/scan/report.json)
        if [ $critical -gt 0 ]; then
          echo "Deployment blocked: $critical critical CVEs detected."
          exit 1
        fi

This process integrates with Red Hat Advanced Cluster Security for Kubernetes.

Supply chain security with Tekton Chains

Tekton Chains operates as a Kubernetes controller that watches for pipeline completion to automatically secure build artifacts through cryptographic signing.

Tekton Chains capabilities

Tekton Chains automatically:

• Signs images using Cosign
• Generates Software Bill of Materials (SBOMs)
• Provides attestations
• Integrates with Sigstore for keyless signing

This allows Red Hat OpenShift to verify every image before running it.

Example: Signing a container image

The following Tekton task signs the image:

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: sign-image
spec:
  params:
    - name: IMAGE
  steps:
    - name: sign
      image: gcr.io/projectsigstore/cosign
      script: |
        cosign sign --key k8s://tekton-chains $(params.IMAGE)

Deployment security on OpenShift

Ensuring a secure runtime environment requires strictly controlling which images are allowed to enter the cluster based on their provenance and compliance status.

Using Red Hat Quay for image storage

If you push to Red Hat Quay:

• Image scanning is automatic.
• CVE reports are generated.
• You can block images that violate policies.

Using Red Hat Advanced Cluster Security for Kubernetes to block unsafe deployments

Red Hat Advanced Cluster Security for Kubernetes can enforce strict admission criteria by requiring that all images be cryptographically signed, free of critical vulnerabilities, and accompanied by a valid Software Bill of Materials (SBOM) before they are permitted to run. It can stop a deployment before it reaches production.

Example deployment policy violation:

Policy Violated: "Unsigned Image"
Deployment blocked.

Example end-to-end CI/CD pipeline (simplified)

The following YAML snippet demonstrates how to string these tasks together into a cohesive pipeline:

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: secure-cicd
spec:
  params:
    - name: image
  tasks:
    - name: fetch-source
      taskRef: { name: git-clone }
    - name: scan-secrets
      taskRef: { name: scan-for-secrets }
    - name: build-image
      runAfter: [scan-secrets]
      taskRef: { name: buildah }
    - name: vulnerability-scan
      runAfter: [build-image]
      taskRef: { name: image-scan }
    - name: cve-check
      runAfter: [vulnerability-scan]
      taskRef: { name: cve-policy-check }
    - name: sign
      runAfter: [cve-check]
      taskRef: { name: sign-image }
    - name: deploy
      runAfter: [sign]
      taskRef: { name: openshift-deploy }

This pipeline:

1. Checks for exposed secrets.
2. Builds securely.
3. Scans for vulnerabilities.
4. Enforces CVE policy.
5. Signs the image.
6. Deploys only after all gates are clean.

Conclusion

Security in CI/CD is essential and must be integrated into every stage of the software lifecycle. You can use Tekton Pipelines, Red Hat OpenShift, and IBM cloud services to build automated pipelines that focus on security.

By managing secrets externally, enforcing policy gates, signing images, generating SBOMs, and validating deployments with ed Hat Advanced Cluster Security for Kubernetes, organizations can deliver software faster and more securely. This combination supports a trusted software supply chain.