Zero trust security and dynamic credentials on OpenShift

In my previous article, we explored externalizing secrets using the External Secrets Operator (ESO). This follow-up addresses the next step in DevSecOps evolution: eliminating long-term secrets in favor of dynamic, ephemeral credentials and advanced network isolation.

For architects and site reliability engineers operating on Red Hat OpenShift, the goal is to transform the pipeline from a consumer of static passwords into an entity with a verifiable identity, capable of negotiating "just-in-time" (JIT) access.

Zero trust architecture for pipelines

The logical diagram in Figure 1 illustrates the authentication and authorization flow between components.

Workload identity

There is no longer a static "secret zero." Identity is guaranteed by the OpenShift ServiceAccount token, which is cryptographically signed and verified by HashiCorp Vault via the TokenReview API.

Network isolation: User-defined networks

For high-security multi-tenant environments, such as banking or telecommunications, standard NetworkPolicies might not suffice. With OpenShift 4.18 and later, user-defined networks (UDN) allow for complete Layer 2/3 isolation for critical pipeline namespaces.

Here is an example of how to set up a user-defined network. This manifest isolates pipeline traffic in a dedicated overlay network, preventing lateral movement from other compromised pods in the cluster.

apiVersion: network.openshift.io/v1
kind: UserDefinedNetwork
metadata:
  name: secure-pipeline-net
  namespace: ci-cd-secure
spec:
  topology: Layer3
  layer3:
    role: Primary
    subnets:
      - cidr: 10.0.128.0/24
        hostSubnet: 24

Requesting temporary credentials with Vault

Instead of using a static secret, we use the VaultDynamicSecret custom resource to instruct the External Secrets Operator to request credentials only when they are needed.

Example: A database migration pipeline requiring DDL privileges only while the task is running.

apiVersion: generators.external-secrets.io/v1alpha1
kind: VaultDynamicSecret
metadata:
  name: dynamic-db-creds
  namespace: ci-cd
spec:
  # Database engine path configured in Vault
  path: "database/creds/pipeline-migration-role"
  method: "GET"
  provider:
    server: "http://vault.vault.svc:8200"
    auth:
      kubernetes:
        mountPath: "kubernetes"
        role: "pipeline-role"
        serviceAccountRef:
          name: "pipeline-sa"

Consumption in Tekton: Volume vs. env var

Important: Never inject dynamic secrets as environment variables (env). If the secret rotates or expires during execution, the process will not see the new value. Always use volumeMounts, as Kubernetes updates files in the volume atomically.

An optimized Tekton task:

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: flyway-migration
spec:
  stepTemplate:
    volumeMounts:
      - name: db-creds
        mountPath: /etc/secrets
        readOnly: true
  steps:
    - name: migrate
      image: flyway/flyway:latest
      script: |
        #!/bin/sh
        # Reads fresh credentials from the filesystem at runtime
        export FLYWAY_USER=$(cat /etc/secrets/username)
        export FLYWAY_PASSWORD=$(cat /etc/secrets/password)
        
        flyway -url=jdbc:postgresql://prod-db:5432/mydb migrate
  volumes:
    - name: db-creds
      secret:
        secretName: db-dynamic-secret # Generated by ESO

Reverse sync: The PushSecret pattern

In hybrid scenarios (such as when an on-premise OpenShift updates a service on IBM Cloud or Azure), use PushSecret to propagate certificates or keys generated by the pipeline to an external vault.

apiVersion: external-secrets.io/v1alpha1
kind: PushSecret
metadata:
  name: push-generated-cert
  namespace: ci-cd
spec:
  refreshInterval: 10s
  deletionPolicy: Delete
  secretStoreRefs:
    - name: ibm-secrets-manager
      kind: ClusterSecretStore
  selector:
    secret:
      name: generated-mtls-cert # Secret created by the pipeline
  data:
    - match:
        secretKey: tls.crt
        remoteRef:
          remoteKey: imported-certs/app-cert

Security context and compliance

To ensure compliance with Red Hat Advanced Cluster Security for Kubernetes, every task must operate with minimal privileges.

• Drop capabilities: Remove all capabilities in the SecurityContext.
• Seccomp profile: Apply RuntimeDefault.
• Short time to live (TTL): Configure Vault roles with a maximum TTL equal to the Tekton task timeout (such as 15 minutes).

Vault role configuration (HCL snippet):

path "database/creds/pipeline-migration-role" {
  capabilities = ["read"]
  ttl = "15m"
  max_ttl = "1h"
}

Conclusion

Adopting dynamic credentials on OpenShift transforms security from "perimeter defense" to "continuous verification." By combining Tekton, the External Secrets Operator, and the new user-defined networks, you can build pipelines that possess no secrets but rent them only for the milliseconds required for execution, drastically reducing the attack surface of the software supply chain.