CNTRLPLANE-2938: update kms EP with plugin image certification and signature verification#2029
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@flavianmissi: This pull request references CNTRLPLANE-2938 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set. 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 openshift-eng/jira-lifecycle-plugin repository. |
flavianmissi
changed the title
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
flavianmissi
changed the title
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
| - Encrypt/decrypt operations under various conditions | ||
| - Plugin behavior during upgrades and migrations | ||
|
|
||
| Vendors extract the test binary from the release payload and execute it against |
There was a problem hiding this comment.
Can we add details about how we will prohibit the usage of arbitrary images?.
There was a problem hiding this comment.
I'm not sure if there's an effective way to prevent this. We can only make it easier for customers to do the right thing, but as far as I know there aren't any hard checks we can do without hard-coding things in OpenShift's payload (which I don't think we should do).
What did you have in mind?
| `ClusterImagePolicy` example: | ||
| ```yaml | ||
| apiVersion: config.openshift.io/v1alpha1 | ||
| kind: ClusterImagePolicy |
There was a problem hiding this comment.
I think, this is an elegant way of fixing our problem.
flavianmissi
force-pushed
the
image-verification-and-certification
branch
6 times, most recently
from
87660ad to
9d7d987
Compare
flavianmissi
force-pushed
the
image-verification-and-certification
branch
from
9d7d987 to
0ea7719
Compare
flavianmissi
force-pushed
the
image-verification-and-certification
branch
from
0ea7719 to
b0d2180
Compare
|
/retitle CNTRLPLANE-2938: update kms EP with plugin image certification and signature verification |
openshift-ci
Bot
changed the title
openshift-ci
Bot
removed
the
do-not-merge/work-in-progress
|
@flavianmissi: 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. |
| Users must create a `ClusterImagePolicy` resource to configure OpenShift to | ||
| verify the image signature every time CRI-O pulls a plugin image. Users should | ||
| obtain the vendor's public key from the vendor's official documentation (e.g., | ||
| HashiCorp's documentation for the Vault KMS plugin). |
There was a problem hiding this comment.
It'd be great if we could prevent users from using arbitrary images.
This might be very difficult... unless we take ownership for shipping the ClusterImagePolicy resource with the right set of approved public key(s).
There was a problem hiding this comment.
We already have a precedent for shipping a ClusterImagePolicy: https://github.com/openshift/cluster-update-keys/blob/main/manifests.rhel/0000_90_openshift-cluster-image-policy.yaml
There was a problem hiding this comment.
What if we don't create a key in key-controller, unless there is a respective ClusterImagePolicy resource for the given image?.
There was a problem hiding this comment.
The thing with shipping a ClusterImagePolicy in the payload is that we would need to hardcode the public key the vendor used to sign the plugin image. If they change the key between plugin versions, the key in openshift's payload would also need to change.
There was a problem hiding this comment.
What if we don't create a key in key-controller, unless there is a respective ClusterImagePolicy resource for the given image?.
How are we going to detect a ClusterImagePolicy? We could document a label users could use? We must keep in mind that vendors might update the key they use to sign their images, in which at some point more than one ClusterImagePolicy will exist in the cluster for the same repository.
There was a problem hiding this comment.
We already have a precedent for shipping a ClusterImagePolicy: https://github.com/openshift/cluster-update-keys/blob/main/manifests.rhel/0000_90_openshift-cluster-image-policy.yaml
Yes, the difference is that we (red hat) don't control the keys used to sign kms plugin images, while the keys in that repository are all controlled by us (red hat).
There was a problem hiding this comment.
It'd be great if we could prevent users from using arbitrary images.
This is a very good point. It largely depends on the actual functional requirement.
It seems that when no policy is defined, no verification is performed and we end up running unverified images.
If a policy is defined, it may contain an untrusted key used for verification, which leads to the same outcome: running unverified images.
There was a problem hiding this comment.
The problem with image verification is that we need a public key from the image signer (vendor, i.e. vault) to verify the image. Unless we're willing to hard-code this public key in OpenShift's payload, there's no way to effectively block use of arbitrary images.
This challenge is inherent to the problem of not delivering images in the release payload. There's nothing we can do without hard-coding something in the payload (i.e image reference, public key, etc.).
I can't think it's a good idea to hard-code something we have no control over the lifecycle.
| Users must create a `ClusterImagePolicy` resource to configure OpenShift to | ||
| verify the image signature every time CRI-O pulls a plugin image. Users should | ||
| obtain the vendor's public key from the vendor's official documentation (e.g., | ||
| HashiCorp's documentation for the Vault KMS plugin). |
There was a problem hiding this comment.
What if we don't create a key in key-controller, unless there is a respective ClusterImagePolicy resource for the given image?.
5 participants
No description provided.