A GitHub Actions secret stores a sensitive value for use in a workflow. Use one for deployment credentials and configuration instead of committing those values to workflow YAML or shell scripts. Keeping values out of code protects them from people who can read the repository and makes the deployment code easier to reuse. section 8.9.7
To configure a deployment workflow:
- Prepare the values it needs: CONTAINER_REGISTRY, REGISTRY_UN, REGISTRY_PW, and KUBE_CONFIG. The last is a Base64-encoded kubectl configuration file. Before copying it, check that it contains credentials only for the cluster the pipeline needs. section 8.9.5 section 8.9.9
- In the repository’s Settings, open the secrets page and choose New Repository Secret. Enter each name and value, then save it. Secrets can instead be added at the organization level when values need to be shared across repositories. section 8.9.9
- Keep another secure record of each value: after saving a secret, you cannot view its value on that page. section 8.9.9
Pass registry values to deployment scripts
A workflow can set CONTAINER_REGISTRY, REGISTRY_UN, and REGISTRY_PW from secrets as environment variables for build, publish, and deployment scripts. VERSION can come from github.sha instead; it is a GitHub context value, not one of the stored secrets. section 8.9.7 section 8.11
env:
VERSION: ${{ github.sha }} #1
CONTAINER_REGISTRY: ${{ secrets.CONTAINER_REGISTRY }} #2
REGISTRY_UN: ${{ secrets.REGISTRY_UN }} #3
REGISTRY_PW: ${{ secrets.REGISTRY_PW }} #3
The workflow YAML shows the env mapping and the `${{ secrets.NAME }}` syntax used for registry values. section 8.9.7
- uses: tale/kubectl-action@v1 #1
with:
base64-kube-config: ${{ secrets.KUBE_CONFIG }} #2
kubectl-version: v1.24.2 #3
A kubectl action reads `${{ secrets.KUBE_CONFIG }}` through its base64-kube-config input so the runner can connect to Kubernetes. section 8.9.6
Add every required secret before expecting deployment to succeed. If a workflow fails, inspect its error and compare the workflow’s environment variables with the values used locally; check that each required secret was added. GitHub secrets serve the deployment workflow, while Kubernetes Secrets or Vault are alternatives to consider for other sensitive configuration needs. section 8.9.10 section 12.5.2
