Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't enforce container sigpolicy by default #230

Merged
merged 1 commit into from
Dec 18, 2023

Conversation

cgwalters
Copy link
Collaborator

(Draft for discussion, also this depends on #229 )

--

Don't enforce container sigpolicy by default

Closes: #218

Basically this effort has not been really successful and adds
more pain than it solves. We need to have a solution that works
for podman too.

In many scenarios, TLS is sufficient - or at least, we're far
from the only thing that if fetched from a compromised server
would result in a compromised system (e.g. privileged containers).

Signed-off-by: Colin Walters walters@verbum.org


Copy link

openshift-ci bot commented Dec 15, 2023

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@cgwalters
Copy link
Collaborator Author

/test all

@cgwalters
Copy link
Collaborator Author

/retest

Copy link

@sallyom sallyom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree enforcing signature verification by default is causing more pain than good at this stage (and afaict everybody using bootc currently adds the --target-no-signature-verification). There's this rpm-ostree issue and general confusion about how to sign & verify. It's still easy enough to configure enforcing signature verification. This should be opt-in for now and enforcing by default should include clear documentation about how to correctly sign and verify (GPG, sigstore, keys, keyless).

@cgwalters
Copy link
Collaborator Author

/test all

Copy link
Member

@vrothberg vrothberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not fan of opt-in security (signature verification). Why would bootc behave differently than other github.com/containers tools? If /etc/containers/policy.json is configured, I expect all tools to adhere to it. So this change worries me.

@cgwalters
Copy link
Collaborator Author

cgwalters commented Dec 18, 2023

Why would bootc behave differently than other github.com/containers tools? If /etc/containers/policy.json is configured, I expect all tools to adhere to it. So this change worries me.

That's exactly it - currently (before this change) bootc does explicitly behave differently (to try to enforce a policy is enabled by default). After, it doesn't, it behaves the same way podman (and docker still AFAIK) do with podman|docker pull.

@cgwalters cgwalters force-pushed the no-sigverify branch 2 times, most recently from 2f70559 to cc28140 Compare December 18, 2023 19:58
Closes: containers#218

Basically this effort has not been really successful and adds
more pain than it solves.  We need to have a solution that works
for podman too.

In many scenarios, TLS is sufficient - or at least, we're far
from the only thing that if fetched from a compromised server
would result in a compromised system (e.g. privileged containers).

Signed-off-by: Colin Walters <walters@verbum.org>
@cgwalters
Copy link
Collaborator Author

OK passing CI, and we now also drop this new default value out of the spec/status struct.

@cgwalters cgwalters merged commit f194c46 into containers:main Dec 18, 2023
10 checks passed
@vrothberg
Copy link
Member

Thanks, @cgwalters ! I must have misread the code.

@jmpolom
Copy link

jmpolom commented Jan 2, 2024

There's coreos/rpm-ostree#4272 and general confusion about how to sign & verify.

As someone who's tried to walk the path to adopt hands off automated container signing in a CI workflow I can say a lot of the "confusion" is really just a lack of good documentation issue. The upstream cosign docs are not great really. Improvements on that end whether directly to the upstream docs or if there were examples in bootc docs would be very helpful to golden path this for users and also show that this is possible today.

The entire way that "keyless" cosign signing works seems good but it seems few people understand how to do it (probably because it is poorly documented) and therefore it is not well tested in many applications. It would be wise to call out signing with static keys and github access tokens as major anti-patterns when using cosign in a CI environment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Back out enforced signature verification by default
4 participants