Orqestria Download
← Zurück zu Team für plattformübergreifende mobile Apps

Skill · Version 1.0.0

Deployment-Geheimnisse und Rechte

Schützt Build- und Deployment-Zugangsdaten durch minimale Identitäten und Trennung von unvertrauenswürdigen Codepfaden.

secrets-deployment-permissions

Teammitglieder mit diesem Skill

Entdecke, wie der Skill hilft

Wann ist der Skill hilfreich?

Nutze ihn bei Cloud-Authentifizierung, CI-Rechten oder Geheimnisbereitstellung für Pull Requests und Releases.

Wobei hilft er dir?

  • Begrenzt CI-Identitäten und bevorzugt eingegrenzte Workload-Authentifizierung.
  • Trennt Umgebungsgeheimnisse von unvertrauenswürdigem Pull-Request-Code.
  • Fixiert Drittanbieter-Actions und prüft fehlende Geheimniskonfiguration.

Das könntest du fragen

Prüfe Zugangsdaten gegen Produktionsgeheimniszugriff aus geforkten Pull Requests. Prüfe einen nicht vertrauenswürdigen PR-Build mit harmloser Zugriffssonde. Er erhält keine Produktionsidentität; der autorisierte Deployment-Job behält engen Umfang.

Ausführliche Dokumentation

Hier findest du die ursprüngliche Anleitung, Beispiele und Prüfschritte des Skills in ihrer Originalsprache.

Details…Weniger anzeigen

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.

Enthaltene Dateien 1

  • SKILL.md