← Zurück zu Team für .NET-Desktop-Apps
Entdecke, wie der Skill hilft
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
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.
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
- 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.
- Set workflow-level
- 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.
- Authenticate CI jobs to AWS, Google Cloud, Azure, or npm/PyPI trusted publishers using short-lived OIDC tokens (
- Environment-scoped secrets & approval gates:
- Store production credentials in protected CI Environments (
environment: production) with branch protection rules and required reviewers, isolated completely fromstagingand PR check runners.
- Store production credentials in protected CI Environments (
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
.envfiles, private signing keys (.p12,.keystore,.pem), or service-account JSON files to git. Provide a documented.env.examplewith safe placeholder values and startup validation that fails fast with a clear message naming any missing required secret.
Enthaltene Dateien 1
SKILL.md