-
Notifications
You must be signed in to change notification settings - Fork 86
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
CLID-280: WIP: Copy signatures during M2M #1065
base: main
Are you sure you want to change the base?
Conversation
@sherine-k: This pull request references CLID-280 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 spike to target the "4.19.0" version, but no target version was set. In 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. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sherine-k The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@sherine-k: This pull request references CLID-280 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 spike to target the "4.19.0" version, but no target version was set. In 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. |
@saschagrunert , @wking , @sub-mod , @mtrmac ,
cc @tlwu2013 |
@sherine-k: all tests passed! Full PR test history. Your PR dashboard. 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. I understand the commands that are listed here. |
@sherine-k - could you re-title or put a hold on the PR for it not to be merged |
/label do-not-merge/work-in-progress |
@r4f4: The label(s) In 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. |
Hi @mtrmac, Do you know if files like Example: /etc/containers/registries.d/registry.redhat.io.yaml
registries.conf
With both files above, is containers/image going to get the signatures from |
/hold |
I think that’s reasonable going forward. OCP’s There is a chance that some customers might want to use GPG signatures (even with RHEL 10! conversations ongoing), so keep that in mind, but I don’t think it’s blocking for the first version. (GPG signatures are not exposed as an OCP custom resource either.)
I wouldn’t expect Or maybe |
“Work together”, yes. “Work as hypothesized”, no. In this example, |
For example, for users that do want to configure |
This makes me think that instead of copying keys, oc-mirror might want to
What are your thoughts? |
If I understand the above comment correctly,
Right now that kind of information is not exposed — c/image doesn’t want to promise, as an API, that the set of configuration sources in the environment is never going to expand to new locations / new source types. [E.g., there is a proposal floating around, on cloud-hosted computers, to automatically use registry credentials from the cloud provider’s key service. I don’t know how likely that is to happen, but an API to “return the list of files relevant for the current configuration” would then return misleading results.] In some cases the APIs return “a human-consumable description” which is explicitly not designed to be machine-parseable. I realize that this would need some solution, if the input needs to be the raw RHEL config files.
Reading this, I probably have a rather wrong model about the If the primary input to And, on OCP, I’m afraid I never read much of the At a very high level, I 100% agree that users should only need to define “the set of mirroring relationships” in one place, with tools then both guiding through the mirroring operation, and automatically generating related configurations, to the extent that can be automated, to avoid typos/mistakes, and unnecessary busywork. |
|
This PR is NOT TO BE MERGED.
This is just a POC of what would be needed to start copying / verifying signatures.
The goal of the PR is to initiate discussions with the rest of the OCP community around how signature verification will look like on a disconnected cluster.
One of the priorities is to confirm the system configuration for signature lookup and verification.
This PR demonstrates how to perform a mirror to mirror workflow with signature mirroring :
Command used:
ImageSetConfig - v2config.yaml
/etc/containers/registries.d/registry.redhat.io.yaml
lookaside
here.❓ Is this going to be the OCP node default configuration as well? OCPSTRAT-1245
/etc/containers/registries.d/registry.redhat.io.yaml
/etc/containers/registries.d/sherinefedora:5000.yaml
/etc/containers/registries.d/localhost:55000.yaml
$HOME/.config/containers/registries.d
(no root permissions required)/etc/containers/policy.json
Console output
Verification of signature mirroring