Skip to main content

ci-cd-auth

This skill should be used when the user asks to "use Infisical in CI/CD", "Infisical machine identity", "infisical login universal-auth", "authenticate Infisical without a browser", "Infisical in Docker", "inject secrets in a pipeline", "Infisical Kubernetes/AWS/GCP/Azure auth", or "bootstrap a self-hosted Infisical" — non-interactive Infisical CLI authentication and secret injection for automation.

Source facts

Repository
Agents-Store/codex-plugins
Last source activity
November 1, 2026 at 02:46
Detected SKILL.md language
English
Stars
0
Forks
0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
2 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
ci-cd-auth
description
This skill should be used when the user asks to "use Infisical in CI/CD", "Infisical machine identity", "infisical login universal-auth", "authenticate Infisical without a browser", "Infisical in Docker", "inject secrets in a pipeline", "Infisical Kubernetes/AWS/GCP/Azure auth", or "bootstrap a self-hosted Infisical" — non-interactive Infisical CLI authentication and secret injection for automation.
# Infisical CLI — CI/CD & Machine-Identity Auth For pipelines, containers, and servers, authenticate with a **machine identity** instead of `infisical login` (browser). The pattern is always: log in to get a short-lived access token, export it as `INFISICAL_TOKEN`, then run normal commands. Prefer machine identities over the deprecated service tokens. ## Universal Auth (most common) Create a machine identity with Universal Auth in the Infisical UI, then in the pipeline: ```bash export INFISICAL_TOKEN=$(infisical login \ --method=universal-auth \ --client-id="$INFISICAL_CLIENT_ID" \ --client-secret="$INFISICAL_CLIENT_SECRET" \ --silent --plain) infisical run --projectId="$PROJECT_ID" --env=prod -- npm run build ``` - `--plain` prints only the JWT; `--silent` suppresses update notices — together they make the output safe to capture. - Credentials can also come from `INFISICAL_UNIVERSAL_AUTH_CLIENT_ID` / `INFISICAL_UNIVERSAL_AUTH_CLIENT_SECRET`. - Once `INFISICAL_TOKEN` is set, every subsequent command auto-detects it. - A machine-identity login creates no login profile; the token is all there is. For EU Cloud, a dedicated or a self-hosted instance, set `INFISICAL_DOMAIN` (or pass `--domain` on `login`) so the token is requested from the right instance. - To scope the session to a sub-organization the identity can reach, add `--organization-slug=<slug>`; without it the session uses the organization the identity was created in. - With machine-identity auth there is no `.infisical.json`, so pass `--projectId` explicitly. - In production, also set `export INFISICAL_DISABLE_UPDATE_CHECK=true`. ## Native cloud / platform auth (no stored secret) Each method exchanges a platform-issued identity for an Infisical token — no client secret to manage: ```bash # Kubernetes (uses the pod's service-account token) infisical login --method=kubernetes --machine-identity-id="$MI_ID" \ --service-account-token-path=/var/run/secrets/kubernetes.io/serviceaccount/token --silent --plain # AWS IAM infisical login --method=aws-iam --machine-identity-id="$MI_ID" --silent --plain # GCP (ID token on GCE/Cloud Run, or IAM service-account key) infisical login --method=gcp-id-token --machine-identity-id="$MI_ID" --silent --plain infisical login --method=gcp-iam --machine-identity-id="$MI_ID" \ --service-account-key-file-path=/path/key.json --silent --plain # Azure infisical login --method=azure --machine-identity-id="$MI_ID" --silent --plain # OIDC (GitHub Actions, GitLab CI, etc.) infisical login --method=oidc-auth --machine-identity-id="$MI_ID" --jwt="$ID_TOKEN" --silent --plain # Generic JWT auth (a JWT your own issuer signs) infisical login --method=jwt-auth --machine-identity-id="$MI_ID" --jwt="$JWT" --silent --plain ``` `--jwt` replaces the deprecated `--oidc-jwt`. `--method` covers `universal-auth`, `kubernetes`, `azure`, `gcp-id-token`, `gcp-iam`, `aws-iam`, `oidc-auth` and `jwt-auth` (plus `user` for people). The official Infisical skills list 13 machine-identity auth methods (Universal, Token, Kubernetes, GCP, AliCloud, AWS, Azure, TLS Certificate, OCI, OIDC, JWT, LDAP, SPIFFE); for the ones `login --method` does not cover, authenticate through an SDK or the Infisical Agent. ## Renew an access token ```bash infisical token renew "$INFISICAL_TOKEN" ``` ## Docker Install the CLI in the image (see the `setup` skill), then make `infisical run` the entrypoint so the container fetches secrets at startup: ```dockerfile # Recommended: machine identity at runtime CMD ["infisical", "run", "--projectId", "your-project-id", "--", "npm", "run", "start"] ``` Pass the token in at `docker run` time: ```bash export INFISICAL_TOKEN=$(infisical login --method=universal-auth \ --client-id="$ID" --client-secret="$SECRET" --plain --silent) docker run --env INFISICAL_TOKEN=$INFISICAL_TOKEN your-image ``` Entrypoint script that logs in inside the container, then execs the app: ```sh #!/bin/sh export INFISICAL_TOKEN=$(infisical login --method=universal-auth \ --client-id="$INFISICAL_CLIENT_ID" \ --client-secret="$INFISICAL_CLIENT_SECRET" --plain --silent) # INFISICAL_DOMAIN (set on the container for EU / self-hosted) is read by both commands exec infisical run --projectId "$PROJECT_ID" --env "$APP_ENV" -- node server.js ``` In Docker Compose, set `env_file` or `environment: [INFISICAL_TOKEN]` on the service and use the same `CMD`. ## GitHub Actions sketch ```yaml - name: Build with secrets env: INFISICAL_CLIENT_ID: ${{ secrets.INFISICAL_CLIENT_ID }} INFISICAL_CLIENT_SECRET: ${{ secrets.INFISICAL_CLIENT_SECRET }} PROJECT_ID: ${{ vars.INFISICAL_PROJECT_ID }} INFISICAL_DOMAIN: ${{ vars.INFISICAL_DOMAIN }} # only for EU Cloud / dedicated / self-hosted INFISICAL_DISABLE_UPDATE_CHECK: "true" run: | export INFISICAL_TOKEN=$(infisical login --method=universal-auth \ --client-id="$INFISICAL_CLIENT_ID" --client-secret="$INFISICAL_CLIENT_SECRET" --silent --plain) infisical run --projectId="$PROJECT_ID" --env=prod -- npm run build ``` ## Bootstrap a fresh self-hosted instance Headless first-run setup that creates the admin user, organization, and an instance-admin machine identity: ```bash infisical bootstrap \ --domain="$INFISICAL_DOMAIN" \ --email="$ADMIN_EMAIL" \ --password="$ADMIN_PASSWORD" \ --organization="$ORG_NAME" \ --ignore-if-bootstrapped ``` The command prints JSON that includes the instance-admin machine identity's token (`.identity.credentials.token`) — treat it like root credentials. For Kubernetes, add `--output=k8-secret` with `--k8-secret-name` / `--k8-secret-namespace` to write the result to a Kubernetes Secret instead (it must run inside a pod whose service account can get/create/update Secrets in that namespace). ## Infisical Agent (secrets as files, no `run`) When an application should read secrets from files that stay fresh — or cannot be wrapped by `infisical run` — run the Infisical Agent next to it: `infisical agent --config agent-config.yaml`. It authenticates as a machine identity and renders secrets through Go templates into files (the config can also be passed as base64 in `INFISICAL_AGENT_CONFIG_BASE64`). The agent takes its instance from `infisical.address` in the config, not from `--domain`. For certificates there is `infisical cert-manager agent --config certificate-agent-config.yaml`. Flag details are in the `cli-reference` skill. ## Self-hosted note Set `INFISICAL_DOMAIN` once (or pass `--domain`, a global flag that `login` honors, or set `domain` in `.infisical.json`). `infisical token renew` does not use a login profile, so for any instance other than US Cloud pass `--domain` or set `INFISICAL_DOMAIN` there too. A `--domain` / `INFISICAL_DOMAIN` that names a different instance than the profile you are logged in to makes the command fail (see the `troubleshoot` skill).
View on GitHub