如何获取Kubernetes API资源与子资源列表？RBAC最小权限配置问询

Great question—sticking to the principle of least privilege for Kubernetes RBAC is such a critical best practice, and figuring out exactly which resources and subresources you need can feel a bit like hunting for a needle in a haystack at first. Let’s break this down clearly for you.

1. Permissions to Control Deployment Container Images #

If you want to restrict a role to only updating container images in Deployment specs, here’s the breakdown:

• Core permission: You’ll need the patch verb on deployments resources in the apps API group. Using patch instead of update is better because it only allows partial modifications (aligning perfectly with least privilege) instead of full overwrites of the Deployment object.
• Optional: Add the get verb if you need the role to view existing Deployment configurations to verify image changes.

Example Role definition:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: your-target-namespace
  name: deployment-image-updater
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "patch"]

Quick note: RBAC alone can’t restrict changes to just the spec.template.spec.containers[*].image field. For that level of field-specific control, you’ll need to pair RBAC with a validation tool like ValidatingAdmissionPolicy or OPA Gatekeeper to block unwanted field modifications.

2. How to List All Kubernetes API Resources & Subresources #

List Top-Level Resources #

The kubectl api-resources command is your go-to for a quick overview of all supported resources, including their API groups and namespace scope:

kubectl api-resources -o wide

Filter by a specific API group (like apps for Deployments) with:

kubectl api-resources --api-group=apps -o wide

Find Subresources for a Specific Resource #

Subresources are secondary endpoints attached to main resources (like status or scale). Here are two reliable ways to find them:

• Query the API Server Directly:
  For apps/v1 Deployments, run this to get details including subresources:

  kubectl get --raw /apis/apps/v1 | jq '.resources[] | select(.name == "deployments")'
  

  Look for the subresources field in the output—it’ll list all valid subresources for Deployments.

• Use kubectl explain:
  While it’s meant for field documentation, you can use it to confirm if a subresource exists. For example:

  kubectl explain deployments.status
  

  If the command returns field details, status is a valid subresource for Deployments.

Common Deployment Subresources #

For reference, here are the most useful subresources for Deployments:

• deployments/status: Update or view the Deployment’s current state
• deployments/scale: Adjust the number of replicas
• deployments/rollout: Trigger rollbacks or check rollout progress

3. Extra Tips for Least Privilege RBAC #

• Always use specific API groups (e.g., apps instead of *) and verbs (e.g., patch instead of *) to avoid over-granting permissions.
• Bind roles to specific namespaces using RoleBinding (instead of ClusterRoleBinding) unless you truly need cluster-wide access.
• Audit permissions regularly with kubectl auth can-i to verify your setup. For example:

  kubectl auth can-i patch deployments --namespace=your-target-namespace --as=system:serviceaccount:your-namespace:your-service-account
  

内容的提问来源于stack exchange，提问作者Chris Snell