aws-samples / aws-samples/sample-autonomous-cloud-coding-agents
feat(security): principal-to-repo authorization
- Lingua principale
- TypeScript
- Stelle
- 143
- Fork
- 46
- Merge medio
- 3g 10h
- PR unite (30g)
- 24
Descrizione
**Context:** ROADMAP.md → Credentials and authorization → Principal-to-repo authorization
**Related:** #249, #389 (mentions principal-to-repo when available)
---
## Component
API or orchestration
## Describe the feature
Map Cognito identities (and future auth principals) to allowed repository sets so users can only submit tasks, webhooks, and channel triggers against repos they are authorized to access. Enforce at task creation and admission time (fail-closed).
## Use case
Multi-user deployments cannot rely on shared PATs or implicit trust. Operators need tenant isolation: Alice may trigger work on `org/frontend` but not `org/payments-core`. Without this, any authenticated user with API access can target any onboarded repo.
## Proposed solution
1. Add a `PrincipalRepoAccess` (or equivalent) store: principal identity → allowed `repo` patterns or explicit repo IDs.
2. Validate in `createTaskCore` / webhook processors / channel adapters before hydration.
3. Admin/operator APIs or CDK Blueprint hooks to manage mappings per team.
4. Return `403 REPO_NOT_AUTHORIZED` with clear CLI messaging.
5. Document operator setup in user/developer guides.
## Other information
- Complements per-session IAM scoping (#209) and identity propagation (#249).
- Scheduled triggers (#389) should inherit the same authorization model.
- Design context: `docs/design/SECURITY.md`, `docs/design/API_CONTRACT.md`.
- [ ] This might be a breaking change
Guida per i contributori
Apri la guida per i contributori
Direzione di ricerca
Inizia leggendo docs/design/SECURITY.md e docs/design/API_CONTRACT.md, quindi traccia createTaskCore, i processori webhook e gli adattatori di canale. Definisci come vengono gestite e applicate le mappature da principal a repository prima dell’idratazione, inclusi i trigger pianificati. Il lavoro è completo quando l’accesso non autorizzato fallisce in modo sicuro con 403 REPO_NOT_AUTHORIZED, i messaggi della CLI sono chiari e la configurazione per gli operatori è documentata.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- aws, typescript
- Ambito
- api, authentication, authorization, backend, security
- Tipo di issue
- Funzionalità
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Stato di attività
- Tranquilla
- Chiarezza
- Abbastanza chiara
- Idoneità per principianti
- 35/100