quick q&a

Get user’s permissions using kubectl

Kubernetes supports RBAC authorization out of the box. In short, every Kubernetes user or a service account have permissions to perform certain actions (HTTP verbs) on certain API server resources e.g. pods. To get user’s permissions using kubectl run kubectl auth can-i --list:

Resources                                       Non-Resource URLs                     Resource Names              Verbs   []                                    []                          [create]    []                                    []                          [create]
persistentvolumeclaims                          []                                    []                          [get list watch create delete deletecollection patch update]
pods/exec                                       []                                    []                          [get list watch create delete deletecollection patch update]
pods                                            []                                    []                          [get list watch create delete deletecollection patch update]
events                                          []                                    []                          [get list watch]
pods/log                                        []                                    []                          [get list watch]
configmaps                                      []                                    []                          [get watch list]
                                                [/.well-known/openid-configuration]   []                          [get]
                                                [/api/*]                              []                          [get]
                                                [/api]                                []                          [get]
                                                [/apis/*]                             []                          [get]
                                                [/apis]                               []                          [get]
                                                [/healthz]                            []                          [get]
                                                [/healthz]                            []                          [get]
                                                [/livez]                              []                          [get]
                                                [/livez]                              []                          [get]
                                                [/openapi/*]                          []                          [get]
                                                [/openapi]                            []                          [get]
                                                [/openid/v1/jwks]                     []                          [get]
                                                [/readyz]                             []                          [get]
                                                [/readyz]                             []                          [get]
                                                [/version/]                           []                          [get]
                                                [/version/]                           []                          [get]
                                                [/version]                            []                          [get]
                                                [/version]                            []                          [get]
podsecuritypolicies.policy                      []                                    [global-unrestricted-psp]   [use]

To view another user’s permissions add --as=[user-name] flag. For instance: kubectl auth can-i --list --as=jenkins.

To see a real world example, you can follow my tutorial on installing Jenkins helm chart and then see the permissions of Jenkins service account. Such permissions include creating pods on demand for Jenkins jobs. Have a look at this chart’s template to get a taste of how RBAC is configured.

If you are after more granular information on roles or cluster roles per service account, have a look at this great answer on stack overflow. It suggests using rbac-tool.

Also note that Kubernetes distinguishes between user and service accounts.


That’s it about getting user’s permissions using kubectl.

You can find below articles useful:

DevOps quick q&a

Live reload Node.js app inside Docker container during development

You probably found yourself in a situation when building new docker image of Node.js web app (e.g. express) with the new changes takes a long time. All you wanted is to test your changes fast on a live system…

To achieve that, use docker volumes or bind mounts to map your source code on the workspace to source folder inside Node.js web app container. You can verify the changes reach the container by inspecting the source code inside the container after you make a change on docker host.

In order for node process inside the container to pick up the changes, it needs to reload. Use nodemon for that.

I wrote about it here as well.

When I did all of the above, I didn’t know automation for this exits. Use tilt!

You can find below articles useful:

DevOps quick q&a

Azure-cli in Dockerfile in Alpine

Today we’ll see how to install Azure-cli in Dockerfile when the base image is Alpine.

As you know azure cli allows you to control azure cloud aspects from command line. This may be useful for provisioning azure resources in ci/cd pipelines or automations, for instance. If the pipelines run inside Jenkins agents (e.g. Docker in Docker Jenkins agent, Podman Jenkins agent) which are containerized, you may need to package azure-cli inside them. Let’s see how to install azure-cli in Dockerfile.

Azure-cli installation in Dockerfile

You probably found it challenging to install Azure-cli as part of Dockerfile where the base image is Alpine.

Use below command sequence to achieve that:

RUN apk add --no-cache --update python3 py3-pip 
RUN apk add --no-cache --update --virtual=build gcc musl-dev python3-dev libffi-dev openssl-dev cargo make && pip3 install --no-cache-dir --prefer-binary azure-cli && apk del virtual

RUN apk add --no-cache --update python3 py3-pip installed python and pip. They are needed because azure-cli is basically Python package.

Second RUN installs os packages required for successful azure-cli installation. Then, pip installs azure-cli.

See also relevant discussion on GitHub about installation of azure-cli in alpine.

Why apk add –virtual?

Note that these os packages are installed in a virtual package which is removed after azure-cli installation using apk del virtual. This trick reduces the final built image size.

Note also that Azure CLI is a Python package. That’s why it requires Python and Pip to run. Hence these packages are not removed.

See this great answer on stack overflow about apk add --virtual. Note that apk add --no-cache reduces image size as well.


That’s it about Azure-cli installation in Dockerfile when Alpine is a base image.

Find out recommended Azure books on Amazon.

Find out recommended Azure courses on Pluralsight:

Sign up using this link to get exclusive discounts like 50% off your first month or 15% off an annual subscription)