Managing Sensitive Information with Secrets

Applicable Scenarios: When a pipeline needs to use sensitive information such as passwords, API keys, or access credentials, but you don't want to hardcode them into workflow files or code repositories.

Configuration Instructions

Creating a Secret

Organization-Level Secret:

1. Go to Organization Settings → Secrets and Variables → Organization Secrets.
2. Click New Organization Secret.
3. Enter Name (e.g., PROD_DEPLOY_KEY) and Value.
4. Click New Secret.

Repository-Level Secret:

1. Go to Repository Settings → Secrets and Variables → Repository Secrets.
2. Click New Repository Secret.
3. Enter Name and Value.
4. Click New Secret.

Referencing a Secret in a Workflow

# Managing Sensitive Information with Secrets
stages:
  - name: deploy
    jobs:
      - name: push-to-prod
        runs-on: {ubuntu-24,x64,medium}
        steps:
          - run: |
              ssh -i ${{ secrets.PROD_DEPLOY_KEY }} \
                user@prod-server.example.com \
                "deploy.sh ${{ secrets.PROD_API_TOKEN }}"

The reference syntax is ${{ secrets.SECRET_NAME }}. Secret name rules:

• Only uppercase letters, numbers, and underscores are allowed
• Cannot start with ATOMGIT_ (to avoid conflict with system variables)
• Cannot start with a number

Using a Secret in Container Credentials

jobs:
  - name: private-image-build
    runs-on: {ubuntu-24,x64,medium}
    container:
      image: registry.example.com/myapp:latest
      credentials:
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}

Secret Security Mechanisms

Security Measures	Description
Log Masking	Secret values are automatically replaced with *** in logs
Not Viewable	Once created, the original value cannot be viewed in the interface, only updated or overwritten
Fork Isolation	Workflows triggered by pull_request from forked repositories cannot access repository-level secrets
Environment Approval	Environment-level secrets can be configured with approvers; jobs cannot access them without approval

Important: In the case of a pull_request event, workflows triggered by PRs from forked repositories cannot read repository secrets. This is a security isolation mechanism. If you need to use a secret in a PR pipeline, use the pull_request_target event.