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
inputPullCommandmechanism 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.
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-isjson-field- Parse the output as JSON and extract the field specified byjsonField
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 toaws secretsmanager get-secret-value --secret-id {0}gcp-secret-manager- Expands togcloud 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.