-
Notifications
You must be signed in to change notification settings - Fork 91
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
Inject payload's system store with proxy CA when specified #172
Conversation
/hold This looks weird to me. Please link me to the requirements for this. |
Adding WIP, this is needlessly complicated now, apparently the |
This PR will now be failing until something starts creating the I suspect the main blocker is |
Added the injection for the operator as well, similarly to openshift/cluster-image-registry-operator#340 but without the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/hold
I do not think this will work.
@stlaz now that [1] and [2] have merged, operators/operands requiring proxy support should no longer be blocked from implementing this feature. |
@stlaz @bparees has suggested to make the ca bundle mount optional. He doesn't want an operator to fail to schedule, causing a domino effect of failures. Operator's can successfully start without the CA trust bundle and then restart when the bundle is available. |
af21cb5
to
03ebe5b
Compare
@danehans I made the CM optional, then. I don't think we'll need to restart the pod, we're dynamically reloading our transports for given CAs, I just added the reload for the system-default trust store, too. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mount the CA bundle at a standard path and have the operator use it where it needs to (route, OpenID, etc).
c2b376d
to
4b95ae8
Compare
86de23b
to
d37494f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After these comments are addressed I am going to want to look at this more closely locally.
/test e2e-aws |
…st store This uses the CVO to create and watch a CM in openshift-authentication namespace, the name of the CM is prefixed in a way so that the config map's resourceVersion is watched by the authn operator and oauth-server is reloaded upon its change.
/test e2e-aws-upgrade |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: danehans, stlaz 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 |
Even with openshift/cluster-network-operator#296 in mind, I think this is fine. /hold cancel |
/retest Please review the full test history for this PR and help us cut down flakes. |
annotations: | ||
release.openshift.io/create-only: "true" | ||
labels: | ||
config.openshift.io/inject-trusted-cabundle: "true" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
won't CVO stomp this configmap after network operator added the CA ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same below of course
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@danehans ^^
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
presumably not, because of the create-only
annotation...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nvmd. The create-only label will make sure it is not overwritten.
@@ -343,3 +346,12 @@ func encodeOrDie(obj runtime.Object) []byte { | |||
} | |||
return bytes | |||
} | |||
|
|||
func trustedCABytes() []byte { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are these additional to the system trust store? The file only includes some CAs, not all. Especially not possibly required intermediate ones.
trustedCABundleName = systemConfigPrefix + "trusted-ca-bundle" | ||
trustedCABundleKey = "ca-bundle.crt" | ||
trustedCABundleMountDir = "/etc/pki/ca-trust/extracted/pem" | ||
trustedCABundleMountFile = "tls-ca-bundle.pem" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a plain yaml text file would me much more readable than 35 constansts.
@@ -525,7 +532,8 @@ func (c *authOperator) checkDeploymentReady(deployment *appsv1.Deployment, opera | |||
func (c *authOperator) checkRouteHealthy(route *routev1.Route, routerSecret *corev1.Secret, ingress *configv1.Ingress) (ready bool, msg, reason string, err error) { | |||
caData := routerSecretToCA(route, routerSecret, ingress) | |||
|
|||
rt, err := transportFor("", caData, nil, nil) | |||
// merge trustedCA data with router cert in case TLS intercept proxy is in place | |||
rt, err := transportFor("", append(caData, trustedCABytes()...), nil, nil) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this reads the file on every request, not good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we sure these bytes always append cleanly, i.e. that we have a trailing newline in caData? Looks fragile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ic, we probably reread to get the latest version (which can change in the background).
This appears to miss other usages. We should use the standard construction of proxies and simply get ourselves into the right shape. A fileobserver (not the watchdog, the other one) and the bash glue from OAS ought to get this into shape. |
/cc @enj @sttts