Git credentials
Similarly to a standalone Buildkite Agent installation, to access and clone private Git repositories, Git credentials must be made available for the Agent to use. These credentials can be in the form of an SSH key for cloning over ssh://, or using a .git-credentials file for cloning over https://.
Cloning repositories using SSH keys
To use SSH to clone your private Git repositories, you'll need to create a Kubernetes Secret containing an authorized SSH private key and configure the Buildkite Agent Stack for Kubernetes to mount this Secret into the checkout container that is used to perform the Git repository cloning.
Create a Kubernetes Secret using an SSH private key
Support for DSA keys was removed from OpenSSH in early 2025. This removal affects buildkite/agent version v3.88.0 and newer. Please migrate to RSA, ECDSA, or EDDSA keys.
After creating an SSH key pair and registering its public key with the remote repository provider (for example, GitHub), you can create a Kubernetes Secret using the SSH private key file.
Ensure that the environment variable name matches the recognized names (SSH_PRIVATE_*_KEY) in docker-ssh-env-config.
SSH_PRIVATE_ECDSA_KEYSSH_PRIVATE_ED25519_KEYSSH_PRIVATE_RSA_KEY
A script from this project is included in the default entry point of the default buildkite/agent Docker image. It will process the value of the Kubernetes Secret and write out a private key to the ~/.ssh directory of the checkout container.
To create a Kubernetes Secret named my-git-ssh-credentials containing the contents of the SSH private key file $HOME/.ssh/id_rsa:
kubectl create secret generic my-git-ssh-credentials --from-file=SSH_PRIVATE_RSA_KEY="$HOME/.ssh/id_rsa" -n buildkite
This Kubernetes Secret can be referenced by the Buildkite Agent Stack for Kubernetes controller using EnvFrom from within the controller configuration or via the gitEnvFrom config of the kubernetes plugin.
Provide a Kubernetes Secret through a configuration file
Using pod-spec-patch, you can specify the Kubernetes Secret containing your SSH private key in your configuration values YAML file using envFrom:
# values.yaml
...
config:
...
pod-spec-patch:
containers:
- name: checkout # <---- this is needed for the secret to only be mounted on the checkout container
envFrom:
- secretRef:
name: my-git-ssh-credentials # <---- this is an example name of the Kubernetes Secret
Provide a Kubernetes Secret using the Kubernetes plugin
Under the kubernetes plugin, specify the name of the Kubernetes Secret via the gitEnvFrom config:
# pipeline.yaml
steps:
- label: ":kubernetes: Hello World!"
command: echo Hello World!
agents:
queue: kubernetes
plugins:
- kubernetes:
gitEnvFrom:
- secretRef:
name: my-git-ssh-credentials # <---- this is an example name of the Kubernetes Secret
If you are using the kubernetes plugin to provide the Kubernetes Secret's SSH private key, you need to define this configuration for every step that requires access to the private Git repository.
If you are defining the Kubernetes Secret using the Buildkite Agent Stack for Kubernetes controller configuration, you'll only needs to configure it once.
Provide an SSH private key to non-checkout containers
The configurations above only provide the SSH private key as a Kubernetes Secret to the checkout container. If Git SSH credentials are required in user-defined job containers, you have these options instead:
- Use a container image based on the default
buildkite/agentDocker image, which preserves the default entry point by not overriding the command in the job spec. - Include or reproduce the functionality of the
ssh-env-config.shscript in the entry point for your job container image to source from recognized environment variable names.
The following example shows how to set up an SSH private key in container-0.
# values.yaml
...
config:
...
pod-spec-patch:
containers:
...
- name: container-0
env:
- name: SSH_PRIVATE_RSA_KEY
valueFrom:
secretKeyRef:
name: my-git-ssh-credentials # <---- this is the name of the Kubernetes Secret to use for container-0 (setup on the same way as the command above)
key: SSH_PRIVATE_RSA_KEY
After setting the SSH key to use on container-0, you need to set up container-0 for git operations. The recommended approach is to implement a pre-command hook to run ssh-keyscan and generate the known_hosts files.
#!/bin/bash
set -eufo pipefail
eval $(ssh-agent -s)
mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/config
chmod 600 ~/.ssh/config
touch ~/.ssh/known_hosts
chmod 600 ~/.ssh/known_hosts
ssh-keyscan github.com >> ~/.ssh/known_hosts
echo "$SSH_PRIVATE_RSA_KEY" | tr -d '\r' | ssh-add -
In your pipeline YAML, you can now add git operations such as git clone in the command step.
# pipeline.yaml
steps:
- label: ":kubernetes: Hello World!"
command: git clone -v git@github.com:{repo_name}.git
plugins:
- kubernetes:
podSpec:
containers:
- image: buildkite/agent:alpine-k8s
Cloning repositories using Git credentials
To use HTTPS to clone private Git repositories, you can use a .git-credentials file stored in a secret, and refer to this secret using the gitCredentialsSecret checkout parameter.
Create a Kubernetes Secret from a Git credentials file
Create a .git-credentials file formatted in the manner expected by the store Git credential helper. After this file has been created, you can create a Kubernetes Secret containing the contents of this file:
kubectl create secret generic my-git-https-credentials --from-file='.git-credentials'="$HOME/.git-credentials" -n buildkite
Provide a Kubernetes Secret through a configuration file
Using default-checkout-params, you can define your Kubernetes Secret as follows through the configuration yaml file:
# values.yaml
...
config:
...
default-checkout-params:
gitCredentialsSecret:
secretName: my-git-https-credentials
If you wish to use a different key within the Kubernetes Secret than .git-credentials, you can project it
to .git-credentials by using items within gitCredentialsSecret.
# values.yaml
...
default-checkout-params:
gitCredentialsSecret:
secretName: my-git-https-credentials
items:
- key: funky-creds
path: .git-credentials
Provide a Kubernetes Secret using the Kubernetes plugin
Under the kubernetes plugin, specify the name of the Kubernetes Secret using the checkout.gitCredentialsSecret config:
# pipeline.yaml
steps:
- label: ":kubernetes: Hello World!"
command: echo Hello World!
agents:
queue: kubernetes
plugins:
- kubernetes:
checkout:
gitCredentialsSecret:
secretName: my-git-https-credentials # <---- this is the name of the Kubernetes Secret (ex. my-git-https-credentials, from command above)
Provide Git credentials to non-checkout containers
The configurations above only provide Git credentials as a Kubernetes Secret to the checkout container. If the .git-credentials file is required in user-defined job containers, you can add a volume mount for the git-credentials volume, and configure Git to use the file within it (for example, with git config credential.helper 'store --file ...').
Skipping checkout (v0.13.0 and later)
To implement the following configuration options, v0.13.0 or newer of the Agent Stack for Kubernetes controller is required.
For some steps, you may wish to avoid checkout (cloning a source repository). This can be done with the checkout block under the kubernetes plugin:
steps:
- label: ":kubernetes: Hello World!"
agents:
queue: kubernetes
plugins:
- kubernetes:
checkout:
skip: true # prevents scheduling the checkout container
Using default-checkout-params
Using default-checkout-params, envFrom can be added to all checkout, command, and sidecar containers separately, either per-step in the pipeline or for all jobs in values.yaml.
Pipeline example (note that the blocks are checkout, commandParams, and sidecarParams):
# pipeline.yml
...
kubernetes:
checkout:
envFrom:
- prefix: GITHUB_
secretRef:
name: github-secrets
commandParams:
interposer: vector
envFrom:
- prefix: DEPLOY_
secretRef:
name: deploy-secrets
sidecarParams:
envFrom:
- prefix: LOGGING_
configMapRef:
name: logging-config
An example of how this would be done using a values.yml configuration file:
# values.yml
config:
default-checkout-params:
envFrom:
- prefix: GITHUB_
secretRef:
name: github-secrets
default-command-params:
interposer: vector
envFrom:
- prefix: DEPLOY_
secretRef:
name: deploy-secrets
default-sidecar-params:
envFrom:
- prefix: LOGGING_
configMapRef:
name: logging-config