Authentication for Chains

Authentication must be set up to take advantage of the following features in Chains:

• Pushing signatures to an OCI registry after signing an image
• Using Fulcio to get Signing Certificates when utilizing Keyless signing.

This doc will cover how to set this up!

Authenticating to an OCI Registry

To push to an OCI registry, the Chains controller will look for credentials in two places. The first place is in the pod executing your Task and the second place is in the service account configured to run your Task.

First we’ll cover creating the credentials.

Set the namespace and name of the Kubernetes service account:

export NAMESPACE=<your namespace>
export SERVICE_ACCOUNT_NAME=<service account name>

Create a Secret based on existing credentials

If you already ran docker login, you can copy the credentials stored in config.json into Kubernetes.

Note: Make sure that any external credentials store, such as the native keychain of the operating system, is not used to store the credentials and the config.json is of the format:

{
  "auths": {
    "<registry>": {
      "auth": "redacted"
    }
  }
}

Create a secret with config.json:

kubectl create secret generic docker-registry \
    --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
    --type=kubernetes.io/dockerconfigjson
    -n $NAMESPACE

More details around creating this secret can be found here.

Create a Secret by providing credentials on the command line

First, you will need access to credentials for your registry (they are in a file called credentials.json in this example). Next, create a Docker config type Kubernetes secret, which will contain the credentials required to push signatures:

Then, create a .dockerconfig type secret:

kubectl create secret docker-registry registry-credentials \
  --docker-server=gcr.io \
  --docker-username=_json_key \
  --docker-email=someemail@something.com \
  --docker-password="$(cat credentials.json)" \
  -n $NAMESPACE

More details around creating this secret can be found here.

Setup credentials using the pod

Tekton supports specifying a Pod template to customize the Pod running your Task. You must supply the Pod template when starting your Task with the cli or embeddng it into your TaskRun.

An example TaskRun configured with the registry-credentials secret.

---
apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: mytaskrun
  namespace: default
spec:
  taskRef:
    name: mytask
  podTemplate:
    imagePullSecrets:
    - name: registry-credentials

More details on how to modify the podTemplate for a taskRun can be found here.

Setup credentials using the service account

Finally, give the service account access to the secret above:

kubectl patch serviceaccount $SERVICE_ACCOUNT_NAME \
  -p "{\"secrets\": [{\"name\": \"registry-credentials\"}]}" -n $NAMESPACE

Now, Chains has push permissions for any TaskRuns running under the service account $SERVICE_ACCOUNT_NAME.

The secrets in the imagePullSecrets attribute of the ServiceAccount are also taken into account. However, other Tekton components may not do so. The secrets attribute is the recommended approach.

Authenticating to Fulcio for Keyless signing

The default deployment will work against public Fulcio assuming it is installed into an EKS or GKE cluster. You will just need to add the following to chains-config ConfigMap data section in the tekton-chains namespace:

  "signers.x509.fulcio.enabled": "true"

Specifying a custom Fulcio endpoint

If you are running your own instance of Fulcio, you need to further configure Fulcio for this. You need to additionally point Chains to your fulcio instance by adding this to chains-config. In this case, it’s a local k8s service, but you will need to change the URL to point to your Fulcio instance.

  "signers.x509.fulcio.address": "http://fulcio.fulcio-system.svc"

Specifying Spiffe as authentication provider

If you are using Spiffe to authenticate to Fulcio, you will need to configure your Chains Deployment to fetch the SVID from the Spire agent. This requires mounting the Agent socket, specifying an environmental variable (if not using the default of /tmp/spire-agent/public/api.sock).

For VolumeMount, replace the k8s SA token, or add if you use it for something else the following to tekton-chains-controller container volumeMounts section:

        - name: spiffe-workload-api
          mountPath: /run/spire/sockets/agent.sock
          readOnly: true

Specify (if necessary) the non-default Agent socket, by adding the following to the tekton-chains-controller env section:

        - name: SPIFFE_ENDPOINT_SOCKET
          value: "/run/spire/sockets/agent.sock"

And finally, adding the volume for the Spiffe workload API by adding this to deployment volumes section:

      - name: spiffe-workload-api
        hostPath:
          path: /run/spire/sockets/agent.sock

Last but not least, thanks to spiffe-csi, which is a CSI (Container Storage Interface) driver for Kubernetes that facilitates injection of the SPIFFE Workload API , there is alternative way of retrieving the Agent socket to your Pods without having to mount the hostPath. You can read more about it here. Once you have installed spiffe-csi-driver into your cluster by following the installation steps in the GitHub repository, the only thing that you have to do is add the following code snippet to deployment volumes and volumeMounts sections:

     ...
        volumeMounts:
          - name: spiffe-workload-api
            mountPath: /spiffe-workload-api
            readOnly: true

     ...
      volumes:
        - name: spiffe-workload-api
          csi:
            driver: "csi.spiffe.io"
            readOnly: true