Great question—those initial approaches work, but we can definitely make this cleaner and more maintainable. Here are three optimized strategies tailored to your use case (CA cert + username/password auth for Artifactory):

1. Combine Secrets + Build Config Native Integration (Project-Scoped, Secure) #

Instead of splitting your config between ConfigMaps and manual steps, bundle all sensitive/artifactory-related data into a single Secret, then let OpenShift's build system handle the rest:

• Step 1: Create a unified Secret
  Package your CA certificate, username, and password into a single Secret (way more secure than ConfigMaps for credentials):

  oc create secret generic artifactory-auth \
    --from-file=ca.crt=./your-artifactory-ca.pem \
    --from-literal=username=your-username \
    --from-literal=password=your-password \
    -n your-build-project
  

• Step 2: Reference the Secret in your Build Config
  Depending on your build type (S2I or Docker), integrate the Secret directly:

  • For S2I builds:
    Add environment variables to inject credentials, and point the SSL CA path to the mounted certificate:

    kind: BuildConfig
    spec:
      strategy:
        sourceStrategy:
          env:
            - name: ARTIFACTORY_USER
              valueFrom:
                secretKeyRef:
                  name: artifactory-auth
                  key: username
            - name: ARTIFACTORY_PASS
              valueFrom:
                secretKeyRef:
                  name: artifactory-auth
                  key: password
            - name: SSL_CERT_FILE
              value: /var/run/secrets/artifactory/ca.crt
          sourceSecret:
            name: artifactory-auth # For pulling source from Artifactory, if needed
      volumes:
        - name: artifactory-ca
          secret:
            secretName: artifactory-auth
      volumeMounts:
        - name: artifactory-ca
          mountPath: /var/run/secrets/artifactory
          readOnly: true
    

    S2I builders will automatically respect the SSL_CERT_FILE variable for secure connections.

  • For Docker builds:
    Mount the Secret and add a quick step to inject the CA into the build container's trust store:

    kind: BuildConfig
    spec:
      strategy:
        dockerStrategy:
          dockerfilePath: Dockerfile
          secrets:
            - secretSource:
                name: artifactory-auth
              mountPath: /var/run/secrets/artifactory
    

    Add these lines to your Dockerfile to trust the CA during the build:

    COPY /var/run/secrets/artifactory/ca.crt /etc/pki/ca-trust/source/anchors/
    RUN update-ca-trust extract
    

2. Cluster-Wide CA Trust (Enterprise-Scale, Zero Per-Build Config) #

If your Artifactory CA is a corporate-wide trusted root, you can add it to OpenShift's cluster-wide CA bundle. This means all builds and pods in the cluster will automatically trust your Artifactory, eliminating per-build CA config entirely:

• Step 1: Add your CA to the cluster config

  # Create a ConfigMap with your CA in the openshift-config namespace
  oc create configmap custom-artifactory-ca \
    --from-file=ca-bundle.crt=./your-artifactory-ca.pem \
    -n openshift-config
  

• Step 2: Update the cluster's image configuration
  Tell OpenShift to use this custom CA for all image-related operations (including builds):

  oc patch image.config.openshift.io/cluster \
    --patch '{"spec":{"additionalTrustedCA":{"name":"custom-artifactory-ca"}}}' \
    --type=merge
  

• Step 3: Handle credentials with a Secret
  You'll still need to create a Secret for your Artifactory username/password (as in Approach 1) and reference it in your build configs—this just removes the CA cert management per build.

3. Tekton Pipelines (Flexible, Reusable Workflows) #

If you're using Tekton for CI/CD (OCP's preferred pipeline tool), you can create reusable Tasks that handle Artifactory auth and CA trust, making your builds consistent across projects:

• Step 1: Store credentials/CA in a Secret
  Same as Approach 1—create a Secret with ca.crt, username, and password.

• Step 2: Create a reusable Task
  Build a Task that injects the CA into the trust store and authenticates to Artifactory:

  apiVersion: tekton.dev/v1beta1
  kind: Task
  metadata:
    name: artifactory-setup
  spec:
    params:
      - name: artifactory-url
        type: string
    volumes:
      - name: artifactory-auth
        secret:
          secretName: artifactory-auth
    steps:
      - name: configure-ca
        image: registry.redhat.io/ubi8/ubi-minimal
        volumeMounts:
          - name: artifactory-auth
            mountPath: /var/run/secrets/artifactory
        script: |
          #!/bin/sh
          cp /var/run/secrets/artifactory/ca.crt /etc/pki/ca-trust/source/anchors/
          update-ca-trust extract
      - name: test-artifactory-access
        image: registry.redhat.io/ubi8/ubi-minimal
        env:
          - name: USERNAME
            valueFrom:
              secretKeyRef:
                name: artifactory-auth
                key: username
          - name: PASSWORD
            valueFrom:
              secretKeyRef:
                name: artifactory-auth
                key: password
        script: |
          #!/bin/sh
          curl -u $USERNAME:$PASSWORD $(params.artifactory-url)/api/v2/ping
  

• Step 3: Use the Task in your Pipeline
  Reference this Task in your Pipeline before any build steps that need to access Artifactory—this ensures consistent setup every time.

Which Approach Should You Choose? #

• Project-scoped builds: Go with Approach 1 (Secrets + Build Config) for simplicity and isolation.
• Enterprise-wide Artifactory use: Approach 2 (Cluster CA) reduces repetitive config.
• Complex CI/CD workflows: Approach 3 (Tekton) offers reusability and flexibility.

内容的提问来源于stack exchange，提问作者Bruno Thiel