[WIP] 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 |
| OpenShift must be able to verify image signatures in air-gapped clusters, and | ||
| public key encryption works well in this scenario. | ||
|
|
||
| In addition to signing their KMS plugin image, vendors will provide OpenShift |
There was a problem hiding this comment.
I don't think we can enforce vendors to implement OpenShift operator (i.e. Vault, AWS, Thales, etc.). Even if we can, that means such important functionality will be deployed as optional operator. Do we really need an operator for this?
Why can't we document and ask cluster-admin manually deploys this resource with advanced security protections?.
There was a problem hiding this comment.
You're right, that would be difficult. I've updated the text to instruct users to do this instead.
| - 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
2 times, most recently
from
7239873 to
8b9a06d
Compare
flavianmissi
force-pushed
the
image-verification-and-certification
branch
from
8b9a06d to
3a0cacf
Compare
|
@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. |
3 participants
No description provided.