OSDOCS-12627/OSDOCS-12728 Sigstore Support #86087
Conversation
openshift-ci
bot
added
the
size/L
|
🤖 Thu Jan 23 15:13:55 - Prow CI generated the docs preview: https://86087--ocpdocs-pr.netlify.app/openshift-enterprise/latest/nodes/nodes-sigstore-using.html |
openshift-ci
bot
added
size/XL
mburke5678
changed the title
|
@QiWang19 PTAL |
QiWang19
left a comment
QiWang19
left a comment
There was a problem hiding this comment.
I just reviewed the nodes-sigstore-configure-cluster-policy.adoc for now.
openshift-ci
bot
added
size/L
QiWang19
left a comment
QiWang19
left a comment
There was a problem hiding this comment.
Reviewed the example output and log according to the PublicKey type imagepolicy example
openshift-ci
bot
added
size/XL
|
@lyman9966 PTAL |
QiWang19
left a comment
QiWang19
left a comment
There was a problem hiding this comment.
The PR Looks good to me. I just left a few minor comments.
| * You have a Sigstore-supported public key infrastructure (PKI), or provide link:https://docs.sigstore.dev/cosign/[Cosign public and private key pair] for signing operations. | ||
| * You have a signing process in place to sign your images. | ||
| * You have access to a registry that supports Cosign signatures. | ||
| * You enabled the required Technology Preview features for your cluster by editing the `FeatureGate` CR named `cluster`: |
There was a problem hiding this comment.
Do we want to explicitly call out the need to mirror Sigstore signatures for OCP release images into your mirror registry before enabling Tech-Preview here? Because if you don't, the openshift ClusterImagePolicy will block your ability to move the CVO Pod to new nodes, or to update to new OCP releases.
There was a problem hiding this comment.
Mirroring Sigstore signatures for OCP release images, is this intended for disconnected users?
I think we should also check if oc-mirror can be mentioned for signature mirroring guidance.
There was a problem hiding this comment.
Without access to the Sigstore signatures, the current openshift ClusterImagePolicy will reject attempts to pull the release image. But with OCPSTRAT-1417 and OCPSTRAT-1869 still undelivered, they can't use oc-mirror for that yet. They'd have to use oc image mirror ... or other lower-level tooling.
There was a problem hiding this comment.
Under this enabled the required Technology Preview bullet, add the following documentation:
Before enabling TechPreview, mirror Sigstore signatures for OCP release images into your mirror registry if mirrors are configured for OCP release image repositories. Otherwise, the openShift ClusterImagePolicy will block your ability to move the CVO Pod to new nodes or update to new OCP releases.
You can use oc image mirror to mirror the signatures. For example:
oc image mirror source.com/image/repo:sha256-1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef.sig \
mirror.com/image/repo:sha256-1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef.sig
@wking @mburke5678 What do you think?
There was a problem hiding this comment.
move the CVO Pod to new nodes
Is this a common thing to do? I am unfamiliar with the CVO. But, I see in the docs that during an update, "the current CVO pod stops, and a CVO pod that uses the new version starts". Is this what you are referring to?
There was a problem hiding this comment.
@wking do you think the above suggestion make sense #86087 (comment)? maybe we should not mention the mirror signature guidance since the oc-mirror is still undelivered
There was a problem hiding this comment.
move the CVO Pod to new nodes
Is this a common thing to do?
ClusterVersion updates will do this, yes. But so will anything that rolls the control plane, e.g. configuring an additional mirror registry or adjusting the Proxy configuration, or otherwise creating a new, drain-inducing MachineConfig targeting the control-plane MachineConfigPool. The MCO will drain the current CVO pod along with everything else from the node being updated, the Deployment controller will replace it with a new CVO Pod, the scheduler will put that CVO pod on a different control-plane Node (because the old one will still be cordoned and draining), and CRI-O will try to pull the new CVO Pod's requested image. Once the control-plane nodes have the tech-preview ClusterImagePolicy in place, CRI-O will reject the CVO/release-image pull unless it can find the Red Hat signature alongside the release image in its configured mirrors.
There was a problem hiding this comment.
This bit:
You can use oc image mirror to mirror the signatures. For example...
seems like a reasonable short-term approach to me, but your wording doesn't call out the importance of the OCP release image signature vs. the openshift ClusterImagePolicy, and "sorry, your CVO is dead unless you can get it back over to a Node that had already pulled that release image" seems like a high-stakes thing to surprise disconnected/restricted-network folks with. But maybe we can find words to go along with the oc image mirror ... advice to make the importance of that particular signature clear?
There was a problem hiding this comment.
@QiWang19 @wking Do I have this right?
If registry mirrors are configured for the {product-title} release image repositories (
quay.io/openshift-release-dev/ocp-releaseandquay.io/openshift-release-dev/ocp-v4.0-art-dev), before enabling the Technology Preview feature set, you must mirror the sigstore signatures for the {product-title} release images into your mirror registry. Otherwise, the defaultopenshiftcluster image policy blocks the ability of the Cluster Version Operator to move the CVO Pod to new nodes, which blocks the node update that results from the feature set change.
mburke5678
force-pushed
the
nodes-sigstore
branch
3 times, most recently
from
c19bcba to
d0a36c6
Compare
mburke5678
added
the
peer-review-needed
xenolinux
added
peer-review-in-progress
xenolinux
left a comment
xenolinux
left a comment
There was a problem hiding this comment.
A few nits; otherwise LGTM
xenolinux
added
peer-review-done
mburke5678
force-pushed
the
nodes-sigstore
branch
from
d0a36c6 to
f3bd084
Compare
|
/retest |
mburke5678
force-pushed
the
nodes-sigstore
branch
from
7431a11 to
6dc06fa
Compare
…for namespaced policies
mburke5678
force-pushed
the
nodes-sigstore
branch
from
5a60459 to
0e9e636
Compare
|
@mburke5678: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions 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-sigs/prow repository. I understand the commands that are listed here. |
|
/cherrypick enterprise-4.18 |
|
@mburke5678: new pull request created: #87533 DetailsIn response to this:
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-sigs/prow repository. |
8 participants
OSDOCS-12627 -- Namepspaced sigstore support added as TP
OSDOCS-12728 -- Cluster-wide sigstore support promoted from DP to TP
Preview:
Nodes -> Manage secure signatures with sigstore -- Minor edits
QE review: