I am trying to configure Kubernetes RBAC in the least-permissive way possible and I want to scope my roles to specific resources and subresouces. I've dug through the docs and can't find a concise list of resources and their subresources.
I'm particularly interested in a the subresource that governs a a part of a Deployment's spec--the container image.
Using kubectl api-resources -o wide shows all the ressources, verbs and associated API-group.
$ kubectl api-resources -o wide
NAME SHORTNAMES APIGROUP NAMESPACED KIND VERBS
bindings true Binding [create]
componentstatuses cs false ComponentStatus [get list]
configmaps cm true ConfigMap [create delete deletecollection get list patch update watch]
endpoints ep true Endpoints [create delete deletecollection get list patch update watch]
events ev true Event [create delete deletecollection get list patch update watch]
limitranges limits true LimitRange [create delete deletecollection get list patch update watch]
namespaces ns false Namespace [create delete get list patch update watch]
nodes no false Node [create delete deletecollection get list patch update watch]
persistentvolumeclaims pvc true PersistentVolumeClaim [create delete deletecollection get list patch update watch]
persistentvolumes pv false PersistentVolume [create delete deletecollection get list patch update watch]
pods po true Pod [create delete deletecollection get list patch update watch]
statefulsets sts apps true StatefulSet [create delete deletecollection get list patch update watch]
meshpolicies authentication.istio.io false MeshPolicy [delete deletecollection get list patch create update watch]
policies authentication.istio.io true Policy [delete deletecollection get list patch create update watch]
...
...
I guess you can use this to create the list of ressources needed in your RBAC config
The resources, sub-resources and verbs that you need to define RBAC roles are not documented anywhere in a static list. They are available in the discovery documentation, i.e. via the API, e.g. /api/apps/v1.
The following bash script will list all the resources, sub-resources and verbs in the following format:
api_version resource: [verb]
where api-version is core for the core resources and should be replaced by "" (an empty quoted string) in your role definition.
For example, core pods/status: get patch update.
The script requires jq.
#!/bin/bash
SERVER="localhost:8080"
APIS=$(curl -s $SERVER/apis | jq -r '[.groups | .[].name] | join(" ")')
# do core resources first, which are at a separate api location
api="core"
curl -s $SERVER/api/v1 | jq -r --arg api "$api" '.resources | .[] | "\($api) \(.name): \(.verbs | join(" "))"'
# now do non-core resources
for api in $APIS; do
version=$(curl -s $SERVER/apis/$api | jq -r '.preferredVersion.version')
curl -s $SERVER/apis/$api/$version | jq -r --arg api "$api" '.resources | .[]? | "\($api) \(.name): \(.verbs | join(" "))"'
done
WARNING: Note that where no verbs are listed via the api, the output will just show the api version and the resource, e.g.
core pods/exec:
In the specific instance of the following resources, no verbs are shown via the api, which is wrong (Kubernetes bug #65421, fixed by #65518):
nodes/proxy
pods/attach
pods/exec
pods/portforward
pods/proxy
services/proxy
The supported verbs for these resources are as follows:
nodes/proxy: create delete get patch update
pods/attach: create get
pods/exec: create get
pods/portforward: create get
pods/proxy: create delete get patch update
services/proxy: create delete get patch update
WARNING 2: Sometime Kubernetes checks for additional permissions using specialised verbs that are not listed here. For example, the bind verb is needed for roles and clusterroles resources in the rbac.authorization.k8s.io API group. Details of these specialised verbs are to be found in the docs here.
You can find the resources list of Kubernetes v1.9 from here: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.9/#-strong-api-overview-strong- . For other K8s versions, check the 'API Reference' section on https://kubernetes.io/docs/reference/
Check the catalog on the left side, for example, 'Workloads' is the high-level overview of the basic types of resources such as Container, Deployment, CronJob etc. And these subresources like 'Container, Deployment, CronJob' are the typical basic Kubernetes API resources.
You can access these basic resources via kubectl, hence there also have a list of 'Resource types' available in https://kubernetes.io/docs/reference/kubectl/cheatsheet/
But I'm confusing in your statement "a the subresource that governs a a part of a Deployment's spec--the container image", if you are trying to manage the permissions of an container image, you should do it on your image registry, but not on Kubernetes side. For example, your registry should has an access controller to do authentication when user pulling images.
for kind in `kubectl api-resources | tail +2 | awk '{ print $1 }' | sort`; do kubectl explain $kind ; done | grep -e "KIND:" -e "VERSION:" | awk '{print $2}' | paste -sd' \n'
I hesitate to even put this as an "Answer", but it is for sure too long for a comment
For the list of resources, are you aware of $HOME/.kube/cache/discovery wherein the Swagger JSON files are persisted to disk by directory that matches their enclosing apiVersion? This is the fastest link I could find (look in the "Discovering and Using CRDs" heading) but ls -la ~/.kube/cached/discovery will show what I mean. Those Swagger JSON files enumerate all the major players within an apiVersion in a way that I find a lot more accessible than the API reference website.
I don't have those files in front of me to know if they contain subresource definitions, so hopefully someone else can weigh in on that.
The minor asterisk to the "weigh in" part is that, based on the surfing I did of the RBAC docs and the 1.9 API reference, I didn't get the impression that a subresource is "field level access" to its parent resource. For example, v1beta1/Evictions is a Pod subresource of /evictions which to the best of my knowledge is not a field within PodSpec
So if you are interested in doing RBAC to constrain a Deployment's image, you may be much happier with Webhook Mode where one can have almost unbounded business logic applied to the attempted request.
来源：https://stackoverflow.com/questions/49396607/where-can-i-get-a-list-of-kubernetes-api-resources-and-subresources