Open tam7t opened 2 years ago
Additional links:
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
specifically runAsUser
, runAsGroup
, fsGroup
and user namespacing
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
Hi Folks, is there any update to the file ownership. Happy to contribute to the code if a decision was made on this already.
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
@aramase Please have a look, the issue is automatically going stale again
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
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.
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.
@aramase can we reopen this issue please ?
@enj Cc: thanks
/reopen
@enj: Reopened this issue.
/lifecycle frozen
/milestone clear
Describe the solution you'd like
Providers return a
MountResponse
with a view of the filesystem and each file has amode
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 beroot
, it may have little practical value.The
atomic_writer.go
also supports a file owner, but theservice.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:
Environment:
kubectl version
): all