Secrets should be read-only by root

[aronchick]

Well designed applications run as non-root, so having secrets only readable by root would improve the levels of defense in depth.

[erictune]

Are you talking about the secrets files on the /tmpfs from the node's view? I agree those should be readable only by root.

Or are you talking about the mount of the secret volume seen inside the container? Those I don't think need to be readable by root-only by default. There is usually only one application inside the container, and it needs to run as a user that can access the secret, so it can use it.

[aronchick]

It's the latter - I can see there being two types of secrets - one that needs accessing by the application running on the container, and one that may be useful in one-time setup. The one-time setup ones could be more sensitive and need hiding from non-root.

[erictune]

@pmorie you had mentioned settable secret file permissions. Anything to add to this conversation?

[pmorie]

@erictune @aronchick I missed the tag into this issue. We've gone around about settable permissions for secrets -- perhaps this is another data point we can use to inform that discussion. @aronchick could you give an example of a secret that shouldn't be readable by non-root UIDs?

[aronchick]

@pmorie Sure - let's say I wanted to do something that required root access to the box / elevated access to my database as the container started (e.g. run a migration, check a mount, etc). I would not want this readable by the account that runs the web server on that container, but I would want it to be available on the container when it starts.

[k8s-github-robot]

@aronchick There are no sig labels on this issue. Please add a sig label by:
(1) mentioning a sig: @kubernetes/sig-<team-name>-misc
(2) specifying the label manually: /sig <label>

Note: method (1) will trigger a notification to the team. You can find the team list here.

[0xmichalis]

/sig node

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close