What this prompt does
This prompt makes the AI generate a least-privilege Kubernetes RBAC configuration for a [cluster_type] cluster shaped around your [team_structure]. It defines ServiceAccounts for [app_accounts], a scoped developer Role in [dev_namespace], an SRE ClusterRole covering [sre_resources], a CI/CD ServiceAccount limited to [deploy_namespaces], a read-only auditor ClusterRole for [compliance_team], bindings mapped to [identity_provider], a permissions matrix table, and a ServiceAccount-label-based NetworkPolicy.
The structure works because it maps RBAC objects directly to real responsibilities rather than handing out broad access. Each persona gets exactly the verbs and resources its job requires — developers can exec and port-forward but not delete PVCs or secrets, the auditor can view but never edit or exec. Producing a permissions matrix makes the whole policy reviewable, so a human can confirm the least-privilege intent instead of trusting a wall of YAML. Driving the design from your actual [team_structure] means the roles match how people really work, which is what keeps the policy maintainable as teams change.
When to use it
- Your cluster runs on over-broad default access and you want to tighten it to least privilege.
- You have distinct dev, SRE, and audit teams that each need different, scoped permissions.
- Application workloads need narrowly-scoped ServiceAccounts (secrets for one, PVC for another, job creation for another).
- A CI/CD pipeline should deploy only to
[deploy_namespaces]and nothing else. - A compliance team needs read-only access for evidence collection without any mutate rights.
- You want a reviewable permissions matrix to confirm who can do what before applying the policy.
Example output
Expect a set of RBAC manifests: ServiceAccount definitions for [app_accounts], Role and ClusterRole objects for developers, SRE, CI/CD, and auditors, the matching RoleBindings and ClusterRoleBindings with [identity_provider] group mappings, a NetworkPolicy keyed to ServiceAccount labels, and a rendered permissions matrix table summarizing each role's allowed verbs against each resource.
Pro tips
- Make
[app_accounts]granular — give each workload only what it needs (secrets for one, PVC for another) rather than a shared catch-all account. - Use the generated permissions matrix as a review artifact; if a cell surprises you, the policy is wrong, not the table.
- Get the
[identity_provider]mapping right, since on EKS the aws-auth ConfigMap is where group-to-role binding actually happens. - Keep destructive verbs off the developer Role deliberately; allowing exec and port-forward while denying delete on PVCs and secrets is the sweet spot.
- Scope the CI/CD account to
[deploy_namespaces]only — a deploy account with cluster-wide write access is a common and dangerous shortcut. - Treat the auditor ClusterRole as strictly read-only for
[compliance_team]; no exec, no edit, no delete keeps SOC 2 evidence collection clean. - Give the SRE ClusterRole only the
[sre_resources]it genuinely needs across namespaces; cluster-wide access is justified for troubleshooting but should still be enumerated, not granted with a wildcard. - Re-derive the matrix whenever
[team_structure]shifts so the bindings never drift out of sync with who actually holds each responsibility.
