Allow file ownership to be set for secrets

[tam7t]

Describe the solution you'd like

Providers return a MountResponse with a view of the filesystem and each file has a mode property. This allows providers to control the file permissions of individual secret files in the mounted filesystem, but there is no control over the file ownership.

The file permissions may be useful but because the owner will always be root, it may have little practical value.

The atomic_writer.go also supports a file owner, but the service.proto does provide a way for file ownership to be specified.

Anything else you would like to add:

A pod with a non-root user should be able to read a secret, and that secret should not be world-readable.

Support for user-names may be difficult and user namespaces will likely need to be considered.

Relevant previous issues:

• Capability to set file-system permissions for mounted secrets #722
• Is it possible to add file attributes when mounting? #346

Environment:

• Secrets Store CSI Driver version: (use the image tag): all
• Kubernetes version: (use kubectl version): all

[tam7t]

Additional links:

https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/2317-fsgroup-on-mount/README.md

specifically runAsUser, runAsGroup, fsGroup and user namespacing

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[nilekhc]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[aramase]

/remove-lifecycle stale

[gobins]

Hi Folks, is there any update to the file ownership. Happy to contribute to the code if a decision was made on this already.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[zioproto]

@aramase Please have a look, the issue is automatically going stale again

[aramase]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[kamialie]

Is there any plan to implement this any time soon? I'm wondering how such a basic thing isn't there in the first place. Does everyone simply run postStart lifecycles hooks or init containers? Seems such an overkill for simply settings permissions during volume mount.

[UXabre]

I would also reckon that it's probably a safe default to take the "runAsUser" and "fsGroup" or "runAsGroup" as file ownership. I also don't understand why this isn't there. It really doesn't help anyone if I have to write some logic to keep changing the ownership, everytime the file is changed (considering auto-rotate). Other people, how don't have the patience or knowledge might just be tempted to run every docker as root just to get this to work which just creates bad practices IMHO.

I get that there aren't many people available, but I've seen a few people offering to help but even that doesn't get any responses? I'd also like to help BTW but I don't know the procedures of this community TBH.

[zioproto]

@aramase can we reopen this issue please ?

[zioproto]

@enj Cc: thanks

[enj]

/reopen

[k8s-ci-robot]

@enj: Reopened this issue.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[enj]

/lifecycle frozen

[enj]

/milestone clear