-
Notifications
You must be signed in to change notification settings - Fork 144
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
Use tmpfs for pki entitlements #1207
Use tmpfs for pki entitlements #1207
Conversation
if [ -d "$ENTITLEMENT_PATH" ]; then | ||
|
||
# do not enable activation key and entitlement at same time. If both vars are provided, prefer activation key. | ||
# when activation keys are used, an empty directory on shared emptydir volume to /etc/pki/entitlement to prevent certificates from being included in the produced container. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you specifically intend to make the methods mutually exclusive, or just to ensure certificates generated by "subscription-manager register" are not included in the final build.
I think we can achieve that ^ without making them mutually exclusive
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And if you do intend to make them mutually exclusive, should we prefer certs? IIUC activation keys require extra handling in the Containerfile, while the certs "just work"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think they should be made mutually exclusive and that is what I did here intentionally. I'd like to document that the etc-pki-entitlement method of storing certs is discouraged and prone to random certificate revocation. Including activation keys now intentionally causes the certs generated by that method to be preferred.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated the PR with more info about my intentions here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the intended direction is activation keys, I think it is fine for that to be the overriding path even if it is more work than certs. The workaround is to remove the configuration for the unused method which should be a best practice anyway.
…ates are not included in final image
…ates are not included in final image this commit updates activation-keys work to mount a temporary directory to /etc/pki/entitlement during the build. This ensure that any certificates generated by subscription-manager register are not included in the final build. Signed-off-by: Brian Cook <bcook@redhat.com>
2d3dcb3
to
230aa36
Compare
only allow 1 method for subscription certs at a time; ensure certificates are not included in final image
this commit updates activation-keys work to mount a temporary directory to /etc/pki/entitlement during the build. This ensure that any certificates generated by "subscription-manager register" are not included in the final build.
The subscription manager team has raised that new processes will revoke generated client subscriptions. On a normal machine using subscription-manager or insights, there is a regeneration process that runs and this is not an issue. In Konflux, when certificates stored as secrets are revoked nothing will regenerate them and it will result in a broken build.
For this reason, they asked us to push people to using activation-keys. This change will prefer activation keys when both are present. Docs updates will also be added to recommend using activation and we would be well positioned to deprecated the etc-pki-entitlement secret in the future.