missing /var/run/secrets/kubernetes.io in builder pod ..

[champak]

Hi Folks,
In trying out Openshift BuildConfigs have run into an oddball issue. When we specify a user (USER ####) in the inline Dockerfile strategy for running the assemble script we find that the pod produced by BuildConfig does not have anything (dir is MIA) at /var/run/secrets/kubernetes.io and the permissions on /var/run/secrets/rhsm are "drwx--------- root root" The pod spec does have a volumemount with the mountpath: /var/run/secrets/kubernetes.io/serveiceaccount.

automountServiceAccountToken is not configured. Any ideas on why we may be in this state ? I was expecting the pod to have /var/run/secrets/kubernetes.io/<> available to USER ####. Thanks for any pointers

[champak]

From a code browse it looked like
8d766bd
may have introduced a change in behavior where the image/assemble script run by build pods get access to /run/secrets/rhsm but not /run/secrets/kubernetes.io. @gabemontero does that sound right ? Also would it be feasible to have an option that allows users to have access to kubernetes.io/.. ? That would let the assemble script authenticate itself with a cert etc. or at least know what namespace it it in.

[gabemontero]

@champak yeah this has been a space of much churn wrt openshift/builder in 2021, with CVEs and regressions of various variety

One thing that is NOT going to happen is mounting of /run/secrets which got you what you want on older 4.x releases without any effort on your part ... that was one of the CVEs recently addressed

Now, @coreydaley is close to getting a changed merged, #245, that would allow you to specify the mounting of specific secrets, assuming one of the SA's secrets is ultimately what you want to pull from /var/run/secrets/kubernetes.io/serveiceaccount

But generally speaking for security reasons, a build has to opt into mounting things under /run/secrets vs. getting everything out of the gate

If there is something other than secrets off of /var/run/secrets/kubernetes.io/serveiceaccount you want then you are in a feature request sort of place ... we typically take those off of our public Jira (what is the best link you would want to point users to that @adambkaplan ?), or we see if @adambkaplan is amenable to classifying this as a feature, and then he takes on creating the appropriate Jira where he wants it.

[champak]

@gabemontero thanks very much for the info ! It certainly makes sense to protect the secrets under the kubernetes.io/serviceaccount/ particularly the token. I was thinking of less confidential info like the namespace. Would be convenient if we could have (by default..) /var/run/secrets/kubernetes.io/serviceaccount/namespace copied into the container where the assemble script runs. This info does not seem to be subject to a privilege escalation vector and some apps may expect it to be around. Thanks !

[gabemontero]

@gabemontero thanks very much for the info ! It certainly makes sense to protect the secrets under the kubernetes.io/serviceaccount/ particularly the token. I was thinking of less confidential info like the namespace. Would be convenient if we could have (by default..) /var/run/secrets/kubernetes.io/serviceaccount/namespace copied into the container where the assemble script runs. This info does not seem to be subject to a privilege escalation vector and some apps may expect it to be around. Thanks !

namespace does seem less innocuous

if not copied into the container's filesystem, I could also see us setting an env var with the value

but again, we are talking feature request

I'm trying to track down the preferred means for you to do so

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

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

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

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

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci]

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

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.