feat(cnbBuild): support builders with different CNB user ids

[pbusko]

Changes

The cnbBuild will read CNB user information from environment variables to enable support for Paketo Jammy builders.

It enforces to run piper as root, the user for CNB lifecycle will be taken from the CNB_USER_ID and CNB_GROUP_ID. When the process is invoked, privileges are dropped down to this gid/uid.

Also this PR introduces two new features to the core packages:

• RunExecutableWithAttrs which allows to pass syscall.SysProcAttr to the execution.

• Recursive Chown

• Tests

• Documentation

[pbusko]

/it-go

[pbusko]

/it-go

[pbusko]

/it-go

[pbusko]

/it-go

[rodibrin]

The Paketo Jammy builders changed the user id handling for security reasons, see https://github.com/orgs/paketo-buildpacks/discussions/188.

To default to user root (and chown the working directory) jeopardizes this.

Instead, use the docker options introduced once for the same topic here: caee8db

[pbusko]

The Paketo Jammy builders changed the user id handling for security reasons, see https://github.com/orgs/paketo-buildpacks/discussions/188.

To default to user root (and chown the working directory) jeopardizes this.

Instead, use the docker options introduced once for the same topic here: caee8db

This change is exactly for the purpose of supporting Jammy/non-Jammy builders simultaneously. On Jenkins we can not run as arbitrary user (which can be effectively anything in CNB), due to the fact that the user must match the UID of the JNLP container (or root), otherwise the dockerExecuteOnKubernetes will fail to start. The change will ensure that the piper step itself will be started as root, and the actual lifecycle steps are running under dynamically configured users via environment variables, hence enabling support for Paketo Jammy and Bionic builders.

Also this change lays down the ground for future support of the CNB Extensions, which require root privileges to invoke Kaniko builds during the extension phase.

[pbusko]

/it-go

[pbusko]

/it-go

[c0d1ngm0nk3y]

All checks have passed

That doesn't sound like Windows should be supported. How to ensure it?

[pbusko]

/it-go

[c0d1ngm0nk3y]

@rodibrin

rodibrin removed the security label

Does this mean you don't have open questions about merging this anymore?

[pbusko]

/it-go

[rodibrin]

Does this mean you don't have open questions about merging this anymore?

my only concern left is about the loss of windows as a testing platform.

Btw: could we remove the dockeroptions, which were (afaiu) invented to pass login data to cnbBuild? Should be replaceable.

[c0d1ngm0nk3y]

my only concern left is about the loss of windows as a testing platform.

If windows should be a testing platform or not, should not be decided on an individual pr where a windows user happened to the reviewer. That should be a goal of the project and the pre-commit checks should at least verify that it is compilable on windows. That is at least my opinion.

Btw: could we remove the dockeroptions, which were (afaiu) invented to pass login data to cnbBuild? Should be replaceable.

Which dockeroptions are you referring to? The one for strating cnbBuild as root?

[rodibrin]

Which dockeroptions are you referring to? The one for strating cnbBuild as root?

yes, Infer Kubernetes securityContext from dockerOpti…

[rodibrin]

If windows should be a testing platform or not, should not be decided on an individual pr where a windows user happened to the reviewer.

the point is that this PR stops windows to be a platform for testing. officially, linux is the only platform supported, however there might be some people around which would appreciate windows support.
If it is possible to make the code buildable on windows with little effort, I'd be happy.

[pbusko]

/it-go

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information