Skip to content

06-secrets.mdx

Latest commit

 

History

History
225 lines (165 loc) · 6.98 KB

06-secrets.mdx

File metadata and controls

225 lines (165 loc) · 6.98 KB

Secrets

Orchestrator supports multiple ways to pull secrets into your build environment. Secrets are transferred to workload containers as environment variables via the provider's native secret system.

Secret Sources

Set secretSource to use a premade integration or custom command. This is the recommended approach

  • it replaces the older inputPullCommand mechanism with a cleaner API.

Premade Sources

Source Value CLI Required
AWS Secrets Manager aws-secrets-manager aws CLI
AWS Parameter Store aws-parameter-store aws CLI
GCP Secret Manager gcp-secret-manager gcloud CLI
Azure Key Vault azure-key-vault az CLI + AZURE_VAULT_NAME env var
HashiCorp Vault (KV v2) hashicorp-vault or vault vault CLI + VAULT_ADDR env var
HashiCorp Vault (KV v1) hashicorp-vault-kv1 vault CLI + VAULT_ADDR env var
Environment Variables env None

Usage

Specify secretSource and pullInputList (comma-separated list of secret keys to fetch):

- uses: game-ci/unity-builder@v4
  env:
    pullInputList: UNITY_LICENSE,UNITY_SERIAL,UNITY_EMAIL,UNITY_PASSWORD
    secretSource: aws-parameter-store
  with:
    targetPlatform: StandaloneLinux64
    providerStrategy: aws
    gitPrivateToken: ${{ secrets.GITHUB_TOKEN }}

The orchestrator fetches each key from the specified source before the build starts. The values are injected as environment variables into the build container.

:::tip AWS users: avoid the 8192-byte container override limit

On AWS ECS/Fargate, all environment variables and secrets are sent in a containerOverrides payload that is limited to 8192 bytes. Using secretSource with pullInputList keeps secret values out of this payload, which is important for workflows with many custom parameters. See Troubleshooting for details.

:::

AWS Secrets Manager

Fetches secrets using aws secretsmanager get-secret-value. Your build environment needs AWS credentials configured (e.g., via AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, or an IAM role).

env:
  pullInputList: UNITY_LICENSE,UNITY_SERIAL
  secretSource: aws-secrets-manager
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
  AWS_DEFAULT_REGION: us-east-1

AWS Parameter Store

Fetches parameters using aws ssm get-parameter --with-decryption. Supports SecureString parameters. Often cheaper and simpler than Secrets Manager for key-value secrets.

env:
  pullInputList: UNITY_LICENSE,UNITY_SERIAL
  secretSource: aws-parameter-store

GCP Secret Manager

Fetches secrets using gcloud secrets versions access latest. Requires gcloud CLI authenticated in the build environment.

env:
  pullInputList: UNITY_LICENSE,UNITY_SERIAL
  secretSource: gcp-secret-manager

Azure Key Vault

Fetches secrets using az keyvault secret show. Requires the AZURE_VAULT_NAME environment variable to specify which vault to use.

env:
  pullInputList: UNITY_LICENSE,UNITY_SERIAL
  secretSource: azure-key-vault
  AZURE_VAULT_NAME: my-game-ci-vault

HashiCorp Vault

Fetches secrets using the vault CLI. Requires VAULT_ADDR to be set. Authentication is handled by standard Vault environment variables (VAULT_TOKEN, AppRole, Kubernetes auth, etc.).

Use hashicorp-vault (or the vault shorthand) for KV v2 secrets engines, or hashicorp-vault-kv1 for KV v1.

env:
  pullInputList: UNITY_LICENSE,UNITY_SERIAL
  secretSource: vault
  VAULT_ADDR: ${{ secrets.VAULT_ADDR }}
  VAULT_TOKEN: ${{ secrets.VAULT_TOKEN }}

By default, secrets are read from the secret mount path. Override with VAULT_MOUNT:

env:
  pullInputList: UNITY_LICENSE,UNITY_SERIAL
  secretSource: hashicorp-vault
  VAULT_ADDR: https://vault.example.com
  VAULT_TOKEN: ${{ secrets.VAULT_TOKEN }}
  VAULT_MOUNT: game-ci

For KV v1 engines:

env:
  pullInputList: UNITY_LICENSE,UNITY_SERIAL
  secretSource: hashicorp-vault-kv1
  VAULT_ADDR: https://vault.example.com
  VAULT_TOKEN: ${{ secrets.VAULT_TOKEN }}

Environment Variables

Reads secrets directly from the process environment. Useful when secrets are already injected by the CI platform (e.g., GitHub Actions secrets).

env:
  pullInputList: UNITY_LICENSE,UNITY_SERIAL
  secretSource: env
  UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}
  UNITY_SERIAL: ${{ secrets.UNITY_SERIAL }}

Custom Commands

If the premade sources don't cover your setup, pass a shell command with {0} as a placeholder for the secret key:

env:
  pullInputList: UNITY_LICENSE,UNITY_SERIAL
  secretSource: 'vault kv get -field=value secret/game-ci/{0}'

The orchestrator runs this command once per key in pullInputList, replacing {0} with each key name.

Custom YAML Definitions

For complex setups, define secret sources in a YAML file:

# .game-ci/secrets.yml
sources:
  - name: my-vault
    command: 'vault kv get -field=value secret/{0}'
  - name: my-api
    command: 'curl -s https://secrets.internal/api/{0}'
    parseOutput: json-field
    jsonField: value

Reference the file path as the secretSource:

env:
  pullInputList: UNITY_LICENSE,UNITY_SERIAL
  secretSource: .game-ci/secrets.yml

The parseOutput field controls how the command output is interpreted:

  • raw (default) - Use the output as-is
  • json-field - Parse the output as JSON and extract the field specified by jsonField

Legacy: inputPullCommand

The older inputPullCommand mechanism is still supported for backward compatibility. If secretSource is set, it takes precedence.

env:
  pullInputList: UNITY_LICENSE,UNITY_SERIAL
  inputPullCommand: aws-secret-manager

The legacy mechanism supports two premade shortcuts:

  • aws-secret-manager - Expands to aws secretsmanager get-secret-value --secret-id {0}
  • gcp-secret-manager - Expands to gcloud secrets versions access 1 --secret="{0}"

New projects should use secretSource instead, which provides more premade sources, better output parsing, and YAML file support.

Provider-Specific Secret Handling

Kubernetes

Secrets are created as native Kubernetes Secret objects and mounted to job containers as environment variables. The orchestrator handles creation and cleanup automatically.

AWS (ECS/Fargate)

Secrets are created as AWS Secrets Manager entries and mounted to Fargate tasks as environment variables via the ECS task definition's secrets configuration.

Local Docker

Secrets are passed as environment variables to the Docker container via -e flags.