Skip to main content
Version: v4 (current)

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

SourceValueCLI Required
AWS Secrets Manageraws-secrets-manageraws CLI
AWS Parameter Storeaws-parameter-storeaws CLI
GCP Secret Managergcp-secret-managergcloud CLI
Azure Key Vaultazure-key-vaultaz CLI + AZURE_VAULT_NAME env var
HashiCorp Vault (KV v2)hashicorp-vault or vaultvault CLI + VAULT_ADDR env var
HashiCorp Vault (KV v1)hashicorp-vault-kv1vault CLI + VAULT_ADDR env var
Environment VariablesenvNone

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-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.