OSASINFRA-3657: Add support for storing OpenStack CA bundles #780
Conversation
|
@stephenfin: This pull request references OSASINFRA-3657 which is a valid jira issue. 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. |
openshift-ci-robot
added
the
jira/valid-reference
|
/cc @mandre |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #780 +/- ##
==========================================
- Coverage 47.01% 46.99% -0.03%
==========================================
Files 97 97
Lines 11874 11877 +3
==========================================
- Hits 5583 5582 -1
- Misses 5676 5679 +3
- Partials 615 616 +1
|
If a CA bundle is required to talk to your OpenStack then obviously all services that talk to the cloud need to have both credentials and said bundle. Currently, these users can get their credentials via cloud credential operator, but they need to source their CA bundle from elsewhere (typically by extracting it from the cloud controller manager's configuration). This makes configuration of services more complicated than necessary. Continue the resolution of the issue by storing the CA bundle, if any, in the root secret on OpenStack. When coupled with the changes introduced in openshift/cloud-credential-operator#780 [1], this allows us to dole out the bundle to anyone who asks for it via a 'CredentialsRequest'. [1] openshift/cloud-credential-operator#780 Signed-off-by: Stephen Finucane <[email protected]>
|
/hold Will wait for 4.19 for this. |
openshift-ci
bot
added
the
do-not-merge/hold
stephenfin
force-pushed
the
OSASINFRA-3657
branch
from
93c3429 to
1f4a8a5
Compare
If a CA cert is required to talk to your OpenStack then obviously all services that talk to the cloud need to have both credentials and said cert. Currently, these users can get their credentials via cloud credential operator, but they need to source their CA cert from elsewhere (typically by extracting it from the cloud controller manager's configuration). This makes configuration of services more complicated than necessary. Begin the resolution of the issue by allowing users (i.e. the Installer) to store the CA cert in their root secret and dole this out to anyone who asks for it via a CredentialsRequest. Follow-up changes will be needed in places like the Installer and csi-operator to start setting/consuming this. Note that the term 'cacert' is important, since this is the terminology used for clouds.yaml files and is what various OpenStack-based tooling like cluster-api-provider-openstack (CAPO) or openstack-resource-controller (ORC) use. Using a different name would necessitate a controller copying the generated secret and changing the key name. Signed-off-by: Stephen Finucane <[email protected]>
stephenfin
force-pushed
the
OSASINFRA-3657
branch
from
1f4a8a5 to
d4d1748
Compare
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: EmilienM, stephenfin The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
If a CA cert is required to talk to your OpenStack then obviously all services that talk to the cloud need to have both credentials and said cert. Currently, these users can get their credentials via cloud credential operator, but they need to source their CA cert from elsewhere (typically by extracting it from the cloud controller manager's configuration). This makes configuration of services more complicated than necessary. Continue the resolution of the issue by storing the CA cert, if any, in the root secret on OpenStack. When coupled with the changes introduced in openshift/cloud-credential-operator#780 [1], this allows us to dole out the cert to anyone who asks for it via a 'CredentialsRequest'. [1] openshift/cloud-credential-operator#780 Signed-off-by: Stephen Finucane <[email protected]>
|
/hold cancel |
openshift-ci
bot
removed
the
do-not-merge/hold
|
@stephenfin: This pull request references OSASINFRA-3657 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 either version "4.19." or "openshift-4.19.", but it targets "4.18.0" instead. 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. |
|
@stephenfin: The following tests failed, say
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. |
|
/test e2e-hypershift |
If a CA bundle is required to talk to your OpenStack then obviously all services that talk to the cloud need to have both credentials and said bundle. Currently, these users can get their credentials via cloud credential operator, but they need to source their CA bundle from elsewhere (typically by extracting it from the cloud controller manager's configuration). This makes configuration of services more complicated than necessary.
Begin the resolution of the issue by allowing users (i.e. the Installer) to store the CA bundle in their root secret and dole this out to anyone who asks for it via a
CredentialsRequest. Follow-up changes will be needed in places like the Installer and csi-operator to start setting/consuming this.