0

Consider the following manifest:

apiVersion: v1
kind: Pod
metadata:
  name: firstpod
spec:
  containers:
  - name: container2
    image: varunuppal/nonrootsudo
    tty: false
    stdin: false

I have read here that tty indicates "

Whether this container should allocate a TTY for itself

so If understand it well, setting it to false, it should not be possible to run into the container with kubectl exec -ti firstpod bash. However, I am still able to do it !!!

I have read this answer bu my problem is the "other way" : I set tty to false but still can execute commands in the container

What did I misunderstand?

Abdelghani
  • 455
  • 2
  • 9
  • 19

2 Answers2

2

kubectl exec is a debugging tool that spawns an additional process inside an existing pod's container. That additional process can independently have a virtual tty attached to it, or not. Separately, you can also usually run an interactive shell with or without a tty attached to it, so long as it can still read commands from its stdin and write responses to its stdout.

In practice you should almost never need to set tty: true for a Kubernetes container. Setting it or not only affects the main process in the container and not anything you launch with kubectl exec or other similar debugging tools.

If your goal here is to prevent kubectl exec then you need to use the Kubernetes permissions system to disallow it. In some cases it may be possible to build a very hardened container that doesn't contain a shell, which would also effectively disable kubectl exec (though it also makes some kinds of debugging much harder); this is only really possible if you're using a compiled language and don't need a complex launcher script (most often, a FROM scratch image for a statically-linked Go program).

David Maze
  • 130,717
  • 29
  • 175
  • 215
  • Thks David for your you answer. My interest is actually didactic and my intention is to understand how the tty: true/false works and how I can check it. maybe a link or (even better) a small command to see the difference. – Abdelghani Sep 11 '20 at 16:17
0

Not so while ago I came across this dive in article into kubectl exec which i think you may find interesting.

Second is this stack case where one of the community user go thru and shows couple of process differences with container started with -i and -t and without those.

Last thing worth to mention that you also have kubectl attach to your disposal:

In addition to interactive execution of commands, you can now also attach to any running process. Like kubectl logs, you’ll get stderr and stdout data, but with attach, you’ll also be able to send stdin from your terminal to the program. Awesome for interactive debugging, or even just sending ctrl-c to a misbehaving application.

The differences here is that the process you interact with. Attach will interact with the one currently running (there is no choice).

acid_fuji
  • 6,287
  • 7
  • 22