Where can I get a list of Kubernetes API resources

Question

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.

Answer 1

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.

Answer 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.

Answer 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.

Answer 4

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