Using secrets in GitHub Actions

For general information about secrets, see 비밀에 대한 정보.

Creating secrets for a repository

리포지토리 소유자만 개인 계정 리포지토리의 GitHub에 비밀 또는 변수를 만들 수 있습니다. 조직 리포지토리에 대한 GitHub에서 비밀 또는 변수를 만들려면 admin 액세스 권한이 있어야 합니다. 마지막으로, 협력자 액세스 권한이 있는 사용자만 REST API를 통해 개인 계정 리포지토리 또는 조직 리포지토리에 대한 비밀 또는 변수를 만들 수 있습니다.

gh secret set SECRET_NAME

gh secret set SECRET_NAME < secret.txt

Creating secrets for an environment

개인 계정 리포지토리에서 환경에 대한 비밀 또는 변수를 만들려면 리포지토리 소유자여야 합니다. 조직 리포지토리에서 환경에 대한 비밀 또는 변수를 만들려면 admin 액세스 권한이 있어야 합니다. 환경에 대한 자세한 내용은 Managing environments for deployment을(를) 참조하세요.

gh secret set --env ENV_NAME SECRET_NAME

gh secret list --env ENV_NAME

Creating secrets for an organization

조직에서 비밀 또는 변수를 만들 때, 정책을 사용하여 리포지토리별로 액세스를 제한할 수 있습니다. 예를 들어 모든 리포지토리에 대한 액세스 권한을 부여하거나 프라이빗 리포지토리 또는 지정된 리포지토리 목록에 대해서만 액세스를 제한할 수 있습니다.

조직 소유자 및 "조직 작업 변수 관리" 또는 "조직 작업 비밀 관리" 권한을 가진 사용자는 조직 수준에서 비밀 또는 변수를 만들 수 있습니다.

자세한 내용은 사용자 지정 조직 역할 소개을(를) 참조하세요.

gh auth login --scopes "admin:org"

gh secret set --org ORG_NAME SECRET_NAME

gh secret set --org ORG_NAME SECRET_NAME --visibility all

gh secret set --org ORG_NAME SECRET_NAME --repos REPO-NAME-1, REPO-NAME-2

gh secret list --org ORG_NAME

Reviewing access to organization-level secrets

You can check which access policies are being applied to a secret in your organization.

1. GitHub에서 조직의 기본 페이지로 이동합니다.

2. 조직 이름에서 설정을 클릭합니다. "설정" 탭이 표시되지 않으면 드롭다운 메뉴를 선택한 다음 설정을 클릭합니다.

   

3. 사이드바의 "보안" 섹션에서 비밀 및 변수를 선택하고 작업을 클릭합니다.

4. The list of secrets includes any configured permissions and policies. For more details about the configured permissions for each secret, click Update.

Using secrets in a workflow

To provide an action with a secret as an input or environment variable, you can use the secrets context to access secrets you've created in your repository. For more information, see 워크플로 실행에 대한 컨텍스트 정보에 액세스 and GitHub Actions에 대한 워크플로 구문.

steps:
  - name: Hello world action
    with: # Set the secret as an input
      super_secret: ${{ secrets.SuperSecret }}
    env: # Or as an environment variable
      super_secret: ${{ secrets.SuperSecret }}

Secrets cannot be directly referenced in if: conditionals. Instead, consider setting secrets as job-level environment variables, then referencing the environment variables to conditionally run steps in the job. For more information, see 워크플로 실행에 대한 컨텍스트 정보에 액세스 and jobs.<job_id>.steps[*].if.

If a secret has not been set, the return value of an expression referencing the secret (such as ${{ secrets.SuperSecret }} in the example) will be an empty string.

Avoid passing secrets between processes from the command line, whenever possible. Command-line processes may be visible to other users (using the ps command) or captured by security audit events. To help protect secrets, consider using environment variables, STDIN, or other mechanisms supported by the target process.

If you must pass secrets within a command line, then enclose them within the proper quoting rules. Secrets often contain special characters that may unintentionally affect your shell. To escape these special characters, use quoting with your environment variables. For example:

Example using Bash

steps:
  - shell: bash
    env:
      SUPER_SECRET: ${{ secrets.SuperSecret }}
    run: |
      example-command "$SUPER_SECRET"

Example using PowerShell

steps:
  - shell: pwsh
    env:
      SUPER_SECRET: ${{ secrets.SuperSecret }}
    run: |
      example-command "$env:SUPER_SECRET"

Example using Cmd.exe

steps:
  - shell: cmd
    env:
      SUPER_SECRET: ${{ secrets.SuperSecret }}
    run: |
      example-command "%SUPER_SECRET%"

Limits for secrets

You can store up to 1,000 organization secrets, 100 repository secrets, and 100 environment secrets.

A workflow created in a repository can access the following number of secrets:

• All 100 repository secrets.
• If the repository is assigned access to more than 100 organization secrets, the workflow can only use the first 100 organization secrets (sorted alphabetically by secret name).
• All 100 environment secrets.

Secrets are limited to 48 KB in size. To store larger secrets, see the Storing large secrets workaround below.

Storing large secrets

To use secrets that are larger than 48 KB, you can use a workaround to store secrets in your repository and save the decryption passphrase as a secret on GitHub. For example, you can use gpg to encrypt a file containing your secret locally before checking the encrypted file in to your repository on GitHub. For more information, see the gpg manpage.

1. Run the following command from your terminal to encrypt the file containing your secret using gpg and the AES256 cipher algorithm. In this example, my_secret.json is the file containing the secret.

   gpg --symmetric --cipher-algo AES256 my_secret.json
   

2. You will be prompted to enter a passphrase. Remember the passphrase, because you'll need to create a new secret on GitHub that uses the passphrase as the value.

3. Create a new secret that contains the passphrase. For example, create a new secret with the name LARGE_SECRET_PASSPHRASE and set the value of the secret to the passphrase you used in the step above.

4. Copy your encrypted file to a path in your repository and commit it. In this example, the encrypted file is my_secret.json.gpg.

   경고

   Make sure to copy the encrypted my_secret.json.gpg file ending with the .gpg file extension, and not the unencrypted my_secret.json file.

   git add my_secret.json.gpg
   git commit -m "Add new secret JSON file"
   

5. Create a shell script in your repository to decrypt the secret file. In this example, the script is named decrypt_secret.sh.

   Shell

   #!/bin/sh
   
   # Decrypt the file
   mkdir $HOME/secrets
   # --batch to prevent interactive command
   # --yes to assume "yes" for questions
   gpg --quiet --batch --yes --decrypt --passphrase="$LARGE_SECRET_PASSPHRASE" \
   --output $HOME/secrets/my_secret.json my_secret.json.gpg
   

6. Ensure your shell script is executable before checking it in to your repository.

   chmod +x decrypt_secret.sh
   git add decrypt_secret.sh
   git commit -m "Add new decryption script"
   git push
   

7. In your GitHub Actions workflow, use a step to call the shell script and decrypt the secret. To have a copy of your repository in the environment that your workflow runs in, you'll need to use the actions/checkout action. Reference your shell script using the run command relative to the root of your repository.

   name: Workflows with large secrets
   
   on: push
   
   jobs:
     my-job:
       name: My Job
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
         - name: Decrypt large secret
           run: ./decrypt_secret.sh
           env:
             LARGE_SECRET_PASSPHRASE: ${{ secrets.LARGE_SECRET_PASSPHRASE }}
         # This command is just an example to show your secret being printed
         # Ensure you remove any print statements of your secrets. GitHub does
         # not hide secrets that use this workaround.
         - name: Test printing your secret (Remove this step in production)
           run: cat $HOME/secrets/my_secret.json
   

Storing Base64 binary blobs as secrets

You can use Base64 encoding to store small binary blobs as secrets. You can then reference the secret in your workflow and decode it for use on the runner. For the size limits, see Using secrets in GitHub Actions.

1. Use base64 to encode your file into a Base64 string. For example:

   On macOS, you could run:

   base64 -i cert.der -o cert.base64
   

   On Linux, you could run:

   base64 -w 0 cert.der > cert.base64
   

2. Create a secret that contains the Base64 string. For example:

   $ gh secret set CERTIFICATE_BASE64 < cert.base64
   ✓ Set secret CERTIFICATE_BASE64 for octocat/octorepo
   

3. To access the Base64 string from your runner, pipe the secret to base64 --decode. For example:

   name: Retrieve Base64 secret
   on:
     push:
       branches: [ octo-branch ]
   jobs:
     decode-secret:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
         - name: Retrieve the secret and decode it to a file
           env:
             CERTIFICATE_BASE64: ${{ secrets.CERTIFICATE_BASE64 }}
           run: |
             echo $CERTIFICATE_BASE64 | base64 --decode > cert.der
         - name: Show certificate information
           run: |
             openssl x509 -in cert.der -inform DER -text -noout
   

Redacting secrets from workflow run logs

GitHub Actions automatically redacts the contents of all GitHub secrets that are printed to workflow logs.

GitHub Actions also redacts information that is recognized as sensitive, but is not stored as a secret. Currently GitHub supports the following:

• 32-byte and 64-byte Azure keys
• Azure AD client app passwords
• Azure Cache keys
• Azure Container Registry keys
• Azure Function host keys
• Azure Search keys
• Database connection strings
• HTTP Bearer token headers
• JWTs
• NPM author tokens
• NuGet API keys
• v1 GitHub installation tokens
• v2 GitHub installation tokens (ghp, gho, ghu, ghs, ghr)
• v2 GitHub PATs

As a habit of best practice, you should mask all sensitive information that is not a GitHub secret by using ::add-mask::VALUE. This causes the value to be treated as a secret and redacted from logs. For more information about masking data, see GitHub Actions에 대한 워크플로 명령.

Redacting of secrets is performed by your workflow runners. This means a secret will only be redacted if it was used within a job and is accessible by the runner. If an unredacted secret is sent to a workflow run log, you should delete the log and rotate the secret. For information on deleting logs, see Using workflow run logs.