4

I am trying to log into a kubernetes pod using the kubectl exec command. I am successful but it logs me in as the root user. I have created some other users too as part of the system build.

Command being used is "kubectl exec -it /bin/bash". I guess this means that run /bin/bash on the pod which results into a shell entry into the container.

Can someone please guide me on the following -

  1. How to logon using a non-root user?
  2. Is there a way to disable root user login?
  3. How can I bind our organization's ldap into the container?

Please let me know if more information is needed from my end to answer this?

Thanks,

Anurag

Anurag
  • 345
  • 1
  • 5
  • 19
  • In general you don't make interactive connections to Kubernetes pods or containers. What's your higher-level goal? – David Maze Aug 14 '18 at 22:53
  • @DavidMaze - Thanks for looking into this! It makes sense most of the times to just rebuild the pod in case of any issues. However, we are trying to run IBM MQ as the middleware/integration messaging solution for a domain which might be shared by many apps. While troubleshooting this product, many a times we have to run some interactive commands to find the root cause. Also, being a shared infrastructure component, it is not tied to a particular app. Hence we need at least some teams to be able to logon and perform operations. We do not want them to logon as root. Hence looking for a solution. – Anurag Aug 15 '18 at 05:31

3 Answers3

3

You can use su - <USERNAME> to login as a non-root user.

Run cat /etc/passwd to get a list of all available users then identify a user with a valid shell compiler e.g

/bin/bash or /bin/sh

Users with /bin/nologin and /bin/false as the set compiler are used by system processes and as such you can't log in as them.

martinkaburu
  • 487
  • 6
  • 18
  • 1
    these steps require to be already logged into the pod. The question asks how to log into the pod in first place – castel Jan 10 '23 at 10:19
2

I think its because the container user is root, that is why when you kubectl exec into it, the default user is root. If you run your container or pod with non root then kubectl exec will not be root.

Bal Chua
  • 1,134
  • 9
  • 10
  • @BaiChua - Can we run containers as a non-root user in Kubernetes? I have an understanding that all containers run as root user. – Anurag Aug 17 '18 at 01:00
  • Yes of course. Best practice is to run as non root. Its not only related to kubernetes but in fact even plain jane docker containers must run as non root. Unless there is a good reason for running as root. – Bal Chua Aug 17 '18 at 04:35
1

In most cases, there is only one process that runs in a Docker container inside a Kubernetes Pod. There are no other processes that can provide authentication or authorization features. You can try to run a wrapper with several nested processes in one container, but this way you spoil the containerization idea to run an immutable application code with minimum overhead.

kubectl exec runs another process in the same container environment with the main process, and there is no option to set the user ID for this process.

However, you can do it by using docker exec with the additional option:

--user , -u    Username or UID (format: <name|uid>[:<group|gid>])

In any case, these two articles might be helpful for you to run IBM MQ in Kubernetes cluster

VAS
  • 8,538
  • 1
  • 28
  • 39
  • Thanks for taking time to answer this question. Yes, it seems reasonable to not run multiple processes inside a container. I also thought about having LDAP installed with IBM MQ using an entry point script; but then, if I follow this pattern, I will start entertaining various monitoring agents and other components too. It will be like building a complete VM and in case of failure, the pod restart time would suffer. Also, I guess, as you mentioned logging in as non-root user is possible with docker, but not with Kubernetes. – Anurag Aug 17 '18 at 01:04
  • So, it looks like that the best way to restrict access on the pods is through Kubernetes security. Or if using a cloud provider which runs managed kubernetes. utilizing the cloud's Identity and access management features can be an option. Basically we should provide only list (limited) access to external groups and admin access to the internal admin users (so that they can exec into pods); all using kubernetes. Is my understanding correct? Is this how generally the industry proceeds with the solution to this issue? Or generally, this is even not considered as a problem at all? – Anurag Aug 17 '18 at 01:17
  • Giving the minimum necessary permissions is a common practice in the industry. Check out my recent answer related to cluster security: https://stackoverflow.com/a/51879760/9521610 – VAS Aug 17 '18 at 09:42