Closed tnozicka closed 3 months ago
This issue is currently awaiting triage.
If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted
label and provide further guidance.
The triage/accepted
label can be added by org members by writing /triage accepted
in a comment.
-i
flag in kubectl exec -i
would disable echo, allowing you to type passwords without them being displayed on the screen.Echoing is disabled by default with -i
, but typed characters are visible in terminal history.-t
flag allocates a pseudo-tty (terminal) for the container. This does not distinguish between standard output and standard error. Both streams are combined and displayed on the terminal.kubectl create secret
to store passwords securely. These secrets are encrypted and accessible to containers through volume mounts or environment variables. Kubernetes Documentation (secrets)Environment Variables: Store passwords securely as environment variables within the container image. Access them using the designated environment variable name inside the container.
Utilize kubectl create secret to store passwords securely.
I can't see how that helps for the case of kubectl exec
. What you are pointing to is how a Pod should be setup for the database (daemon) itself. The issue here is using the database CLI by a particular user, his password shouldn't be exposed to everyone through environment variable or a secret. (Plus the password hashes are stored within the database.)
In our bi-weekly bug scrub meeting, we discussed this issue. Although we agreed upon that this would be a reasonable ask, this should require significant changes to make it happen. /transfer kubectl /triage accepted /priority backlog
In case someone want to have a look at it.
What did you expect to happen? kubectl exec -i should set up terminal in a way that allows disabling echo.
I think you can do this on your own with stty -echo
.
Alternatively, -t should distinguish between stdout and stderr
As far as I understand, this is what allocating a psuedo-tty is inteded for. It creates an "actual" tty device inside the container. It attaches local stdout to the combined remote streams so we can distinguish remote output from local output (kubectl).
I don't think there's anything for us to actually implement here. Feel free to reopen if that's not the case.
/close
@eddiezane: Closing this issue.
What happened?
kubectl exec -i
sets up a terminal that prevents disabling echoing. So when an application ask for a password, it is visible in the terminal.It may seem that adding the
-t
is the way to help out here, but-t
mergesstdout
andstderr
together on purpose, unfortunately. So when you try to redirect the output of such command into a variable (orstdout
to a file), you will never see the "Password: " promt because it gets written intostdout
because of howkubectl exec -it
sets up the terminal using raw option./sig cli
What did you expect to happen?
kubectl exec -i
should set up terminal in a way that allows disabling echo. Alternatively,-t
should distinguish betweenstdout
andstderr
.How can we reproduce it (as minimally and precisely as possible)?
kubectl run test --image=registry.access.redhat.com/ubi9/ubi:9.3-1610@sha256:66233eebd72bb5baa25190d4f55e1dc3fff3a9b77186c1f91a0abdb274452072 -- sleep infinity
kubectl exec -i pod/test -- passwd
Anything else we need to know?
I have used
passwd
as an example of a tool that ask for password onstderr
and is available to everyone to reproduce this. It doesn't return much useful value onstdout
, so here is a real word example of acqlsh
query that needs to ask for a password first:(password echoed)
(no output but silently expects the password)
Kubernetes version
Cloud provider
OS version
Install tools
Container runtime (CRI) and version (if applicable)
Related plugins (CNI, CSI, ...) and versions (if applicable)