Orqestria Download
← Back to Cross-platform mobile foundation team

Skill · Version 1.0.0

Deployment secrets and permissions

Protects build and deployment credentials through least-privilege identities and separation from untrusted code paths.

secrets-deployment-permissions

Team members using this skill

See how it helps

When is it useful?

Use it when configuring cloud authentication, CI permissions or secret delivery for pull requests and releases.

What does it help you do?

  • Limits CI identities and prefers scoped workload authentication.
  • Separates environment secrets from untrusted pull-request code.
  • Pins third-party actions and validates missing-secret configuration.

Try asking this

Review deployment credentials so a forked pull request cannot access production secrets. Run an untrusted pull-request build with a harmless secret-access probe. It must receive no production identity, while the authorized deployment job retains its narrow scope.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Secrets & Deployment Permissions

CI/CD runners and deployment pipelines hold the keys to production infrastructure and registries. Apply least privilege, short-lived credentials, and strict trust boundaries to every workflow job.

Least-Privilege Pipeline Identities

  1. Default permissions: contents: read:
    • Set workflow-level permissions: { contents: read } (or empty {}) by default, and grant elevated permissions (packages: write, id-token: write, deployments: write) only on the specific job that publishes or deploys.
  2. Prefer Workload Identity / OIDC over long-lived static cloud keys:
    • Authenticate CI jobs to AWS, Google Cloud, Azure, or npm/PyPI trusted publishers using short-lived OIDC tokens (id-token: write) scoped to a specific repository, environment, and branch/tag claim (ref:refs/heads/main) rather than storing non-expiring admin keys in CI secrets.
  3. Environment-scoped secrets & approval gates:
    • Store production credentials in protected CI Environments (environment: production) with branch protection rules and required reviewers, isolated completely from staging and PR check runners.

Supply-Chain & Untrusted Code Defenses

Threat Vector Vulnerable Pattern Mandatory Hardening
Untrusted Fork / PR Execution (pull_request_target) Running pull_request_target and checking out/executing the PR's head commit with access to repo secrets Never run npm install, build scripts, or tests from an untrusted PR head inside pull_request_target. Use unprivileged pull_request workflows for code checks.
Script Injection in Workflow run: Blocks Interpolating untrusted context directly in shell: run: echo "${{ github.event.issue.title }}" Pass untrusted values through env: variables (TITLE: ${{ ... }}) and reference "$TITLE" safely in the shell script.
Mutable Third-Party CI Actions / Orbs Referencing external actions by floating branch or tag (uses: some-org/action@main or @v1) Pin third-party actions to a full 40-character commit SHA (uses: org/action@a1b2c3... # v1.4.2) and audit their permissions.
Secret Leakage in Logs & Artifacts Running env, printenv, set -x around secret variables, or passing secrets via --build-arg in Dockerfiles Never use DOCKER --build-arg for secrets (they persist in docker history); use BuildKit --secret mounts (RUN --mount=type=secret,id=...). Mask dynamic tokens before logging.

Secret Rotation & Zero-Secret Source Invariants

  • Never commit .env files, private signing keys (.p12, .keystore, .pem), or service-account JSON files to git. Provide a documented .env.example with safe placeholder values and startup validation that fails fast with a clear message naming any missing required secret.

Included files 1

  • SKILL.md