'Where can I get a list of Kubernetes API resources and subresources?
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 part of a Deployment's spec--the container image.
Solution 1:[1]
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
Solution 2:[2]
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.
Solution 3:[3]
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.
Solution 4:[4]
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'
Solution 5:[5]
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.
Solution 6:[6]
I wrote a tiny Go utility for this exact purpose. Generates a complete RBAC role with every possible resource & sub-resource on the cluster. You can then prune that back to fit your role's use case.
Solution 7:[7]
Markdown version, using kubectl instead of curl
Here follows a different code snippet, derived from the script posted in the answer by John.
When executed in Bash, it produces a more detailed output in the form of a Markdown table, saved as the file Kubernetes_API_resources.md.
It uses kubectl get --raw ... instead of curl to query the API, and the resulting Markdown file documents its own creation in a code block.
echo "# Kubernetes API resources
Updated on `date -I`
\`\`\`bash
${BASH_COMMAND}
\`\`\`
| API name/version | Resource | Verbs | Kind | Namespaced |
| ---------------- | -------- | ----- | ---- | ---------- |
`
for apipath in $(kubectl api-versions | sort | sed '/\//{H;1h;$!d;x}'); do
version=${apipath#*/}
api=${apipath%$version}
api=${api%/}
prefix="/api${api:+s}/"
api=${api:-(core)}
>&2 echo "${prefix}${apipath}: ${api}/${version}"
kubectl get --raw "${prefix}${apipath}" | jq -r --arg api "${api}/${version}" '.resources | sort_by(.name) | .[]? | "| \($api) | \(.name) | \(.verbs | join(" ")) | \(.kind) | \(if .namespaced then "true" else "false" end) |"'
done
`" > Kubernetes_API_resources.md
Solution 8:[8]
If you are using kubectl krew plug-in, I will suggest using get-all. It can get almost 90% resources. included configmap, secret, endpoints, istio, etc
And It have a great arg --since, you can use it to list out last x min created resources.
example
kubectl get-all --since 1d
Solution 9:[9]
Another option, especially for those who don't have immediate access to a live k8s, is the OpenAPI spec.
From the api reference, you can reach the latest docs which has a link, at the top right, to the git managed OpenAPI spec which you can load at the Swagger live web editor.
Endpoints like /api/v1/namespaces/{namespace}/pods/{name}/log will be listed there.
Placed all these links in an attempt to future-proof this answer. I couldn't find a /latest type URL that'll point to the latest version.
Solution 10:[10]
You can use explain command to get mode details about api-resource and sub resources.
Here I am taking an example of POD api-resource:
kubectl explain pod
KIND: Pod
VERSION: v1
DESCRIPTION:
Pod is a collection of containers that can run on a host. This resource is created by clients and scheduled onto hosts.
If you to want to check more about spec section (sub-resource) of POD, use
kubectl explain pod.spec
For toleration
kubectl explain pod.spec.tolerations
and if you want to get check values and its input type use
kubectl explain pod.spec.tolerations.value
Hope that answers your question
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow