RBAC Role and Binding Manifest Prompt Template

This prompt is built for security engineers and platform operators who need to translate natural language access requirements into valid, least-privilege Kubernetes RBAC manifests. The primary job-to-be-done is generating production-ready YAML for Role, ClusterRole, and RoleBinding resources that will pass automated validation and security audit checks. The user is expected to have a clear understanding of the target namespace, the service account or user subject, and the specific Kubernetes API resources involved. Without this context, the model cannot scope rules correctly and will produce manifests that are either overly permissive or fail to grant necessary access.

The prompt enforces strict RBAC construction rules: correct apiGroups references (empty string for core resources, named groups for others), resource name scoping via resourceNames, and verb restrictions limited to the actual operations required. It actively flags wildcard rules—such as verbs: ['*'] or resources: ['*']—that would fail a security audit and suggests specific alternatives. The output is indentation-correct YAML with proper field ordering, making it suitable for direct piping into kubectl apply --dry-run=client or GitOps workflows. You should wire this prompt into a pipeline that includes a YAML linter and a kubectl auth can-i --list verification step before deployment.

Do not use this prompt for generating NetworkPolicy, PodSecurityPolicy, PodSecurityAdmission, or admission controller configurations. It is not designed for multi-tenancy policy generation, OPA/Rego rules, or dynamic RBAC controller setups. If your access requirements involve non-resource URLs (/healthz, /api/*), custom resource definitions (CRDs) with unknown API groups, or complex aggregated roles, you must provide explicit schema references and additional constraints. For high-risk production environments, always require human review of the generated manifests and run them through a policy-as-code evaluation tool before applying them to a cluster.

This prompt template generates Kubernetes RBAC YAML manifests from natural language access requirements. It is designed to produce manifests that follow least-privilege principles by default, scoping verbs and resources as narrowly as possible. The template includes explicit instructions to avoid wildcard rules, validate API group references, and flag any requested permissions that appear overly broad. Use this when you need to convert a security ticket, access request, or compliance requirement into a valid, audit-ready RBAC manifest that can pass kubectl auth can-i --dry-run checks.

codeCopy
You are a Kubernetes RBAC security engineer. Generate a valid Kubernetes RBAC manifest from the access requirements below.

## Input
[ACCESS_REQUIREMENTS]

## Constraints
- Follow least-privilege principles. Grant only the minimum verbs and resources needed.
- Do NOT use "*" for verbs or resources unless explicitly requested and justified.
- Use specific API group references. Do not assume the core group.
- For RoleBindings, include a specific namespace. For ClusterRoleBindings, confirm cluster-wide scope is intended.
- If the request is ambiguous, ask for clarification before generating the manifest.
- If the requested permissions appear overly broad, add a warning comment in the output.

## Output Schema
Return a single YAML document containing one or more Kubernetes resources. Use the following structure:
```yaml
---
apiVersion: rbac.authorization.k8s.io/v1
kind: [Role | ClusterRole | RoleBinding | ClusterRoleBinding]
metadata:
  name: [RESOURCE_NAME]
  namespace: [NAMESPACE if Role or RoleBinding]
[SPEC_FIELDS]

Validation Checks (perform internally before output)

1. All apiGroups fields are non-empty strings, not "*".
2. All resources fields list specific resource names.
3. All verbs fields list specific verbs (get, list, watch, create, update, patch, delete).
4. RoleBinding subjects have valid kind (User, Group, ServiceAccount) and name.
5. No ClusterRoleBinding is generated unless cluster-wide scope is explicitly requested.

Output Format

Return ONLY the YAML manifest inside a fenced yaml code block. Include a brief audit note after the block if any permissions appear overly broad.

To adapt this template, replace [ACCESS_REQUIREMENTS] with the specific access request, such as "Allow the ci-bot ServiceAccount in namespace staging to read Pods and create Deployments." For high-risk environments, add a [RISK_LEVEL] placeholder that triggers additional scrutiny for cluster-admin or secrets access. After generation, always run the output through kubectl --dry-run=client -f - and kubectl auth can-i checks before applying. For production pipelines, pair this prompt with a validation harness that parses the YAML, checks for wildcard rules, and blocks any manifest that grants more than the requested permissions.

The RBAC prompt is designed to be called from a security review or platform engineering workflow, not from an open chatbot. The typical integration point is a CI/CD pipeline step, a GitOps pre-commit hook, or an internal platform API that accepts a natural-language access requirement and returns a validated manifest. The caller must provide the [NAMESPACE], [SUBJECT_TYPE], [SUBJECT_NAME], and [REQUESTED_ACCESS] placeholders. The prompt should be treated as a generation step, not a final approval step. Every generated manifest must pass automated validation and human review before it reaches a cluster.

Wire the prompt into an application by wrapping it in a function that enforces a strict contract. The function should: (1) accept typed input matching the placeholder schema; (2) call the model with the prompt template and a low temperature (0.0–0.2) to maximize structural consistency; (3) parse the response and validate it against the Kubernetes RBAC API schema using a tool like kubeconform or kubectl --dry-run=server; (4) run a set of policy checks that reject manifests containing wildcard verbs (*), wildcard resources (*), or missing namespace isolation for RoleBindings. If validation fails, the harness should retry once with the error message injected into the [CONSTRAINTS] block. If the retry also fails, the workflow must escalate to a human reviewer and log the full prompt, response, and validation errors for audit.

For production use, integrate an eval harness that runs a golden test suite of known access patterns (e.g., 'read-only Pod viewer in staging', 'read-write Deployment manager in production') and asserts that the generated rules match expected verbs, resources, and scope. Log every generation attempt with the input parameters, model version, generated YAML, validation result, and reviewer identity. Never allow a generated RBAC manifest to be applied automatically without a human approval step, because overly permissive rules can expand the blast radius of a compromised credential. The prompt is a productivity tool for security engineers, not a replacement for least-privilege review.