Bug 1366349

Hi there,
  Not sure if you'd prefer this as a sep bug, but:

  We have a Corp Proxy & Firewall that inspects HTTP & FTP traffic (incl. SSL) and we are required to use it to meet Security Compliance.
  It decodes+re-encodes *all* SSL traffic on the way through, basically injecting a self-signed cert into the chain for the client machines' SSL traffic.
  Because of the self-signed Cert, OpenShift fails the connection because it doesn't trust it.

  We very much want to use tooling like the CDK to enable Dev's to test on their local machines for real-time experimentation and validation.
  We've also tried to do something similar with licensed OSE inside Vagrant with varying success.

  We can see several ways of hacking the OpenShift privileged containers and support scripts to set Proxy settings and inject our self-signed SSL cert (and it doesn't seem overly difficult) but also means having to maintain a fork of the provided containers, which is also not particularly attractive from a compliance POV.

  AFAICT, not being able to easily and safely inject a self-signed SSL cert is a blocking issue for us, so want to understand what sort of work and time-lines are happening to resolve it
  i.e. implied by "... significant work going on with the certificate tooling..." above.

  Thanks.
-will

Cluster-level secrets have been asked for many times and struct down each time because you would effectively lose the ability to partition secrets from individuals that have access to the global resource, ie, global secrets are really not secret at all.  There are also other reasons not to do this such as not wanting to have global and namespaced variants of the same resource, or making a single resource both namespaced and non-namespace.

To get what you want, you could:

- Write a controller that puts a source secret into every namespace
- Keeps those secrets updated when the source secret changes

Paul,

Your response ignores one of the key pieces here.  Specifically automatically mounting those secrets.  The irony with CA certificates is that there's no good reason for them to even be "secret" in the first place.  The trouble is, being able to consistently inject them into the actual pods without consumers of the service always needing to tweak their applications.

Sorry, was on PTO.

Note to interested parties: a documentation bug is open for this issue as well at https://bugzilla.redhat.com/1389761 -- this is intended to address a way to automatically perform the steps required, such as listed by Paul:
- Write a controller that puts a source secret into every namespace
- Keeps those secrets updated when the source secret changes

The docs team has not been able to test and implement a solution so I opened a knowledgebase solution at https://access.redhat.com/solutions/2958391 intended to address these issues. However I have to agree with Mark, this is might be too complex to just shrug off as "write a controller and do yourself", given that we want OpenShift to be accessible out-of-the-box. I'm working on the KCS, but even if I get it done I dont feel comfortable with that being the permanent solution. With that said I'll leave this bz closed for now since we have the docs one open.

Paul, thought about it some more. So, we have a solution to create a secret for every new project, which allows the CA to be accessible to pods in any project. That's the kcs I previously linked (https://access.redhat.com/solutions/2958391) -- I am re-opening this to focus instead on "way to automatically have pods mount a secret in the local namespace". This takes out the "global" part of the issue. Is there a way to make all pods mount a local secret without having to manually edit the dc? I'm also fine with opening a separate RFE.

I also feel that nacking the whole concept just because of secrets is a little narrow of a view; I think our customers would be happy with a way to mount using non-secrets, like the way we do with configmaps or something, just in a more automated way.

may be able to add cert to the ca-bundle as noted under /etc/origin/master/master-config.yaml -> serviceAccountConfig -> masterCA -- given that this is given to every service account including "default", this is automatically mounted into *every* pod. Normally it's used for trusting the master api, but it could also be used as a general CA trust store for any CA, including a customer's firewall CA that is blocking external traffic. This could bypass the need to auto-mount or manually mount secrets; indeed it does away with secrets and makes an already-global resource work to our advantage.

I'd need to test this still and it may take me some time (and I wont be able to do a full test with a firewall re-encrypting traffic like that as I do not have access to this type of system)

https://github.com/openshift/origin/blob/3659383d50503e330aee3b42604c85b8fd019ea9/pkg/cmd/server/api/types.go#L826-L849

If we do (In reply to Steven Walter from comment #12) we could then use http://www.unix.com/man-page/centos/8/UPDATE-CA-TRUST/ to ensure that all applications are able to use the certificates provided by the bundle, effectively (with out involving some interaction on the customer side), thus allowing an admin to define the CA used for interactions with the proxy, and application making connection outbound, without any interaction, can communicate to the proxy.

if the scope of this RFE is how to automatically inject an env or volume mount into pod (from either a secret of configmap) without having to manually edit your deployment specs, the solution on the roadmap for this is the PodPreset resource.

see:
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/pod-preset.md

It lets you define a PodPreset per namespace that says "all pods that match this label selector should have these env vars and volume mounts injected into the pod spec".

The PodPreset resource is alpha through kubernetes 1.7.

Can the customer comment on if PodPreset would meet their need?

As one of the relevant customers, PodPresets would work.

That said, I'm also *very* interested in Steven and Eric's suggestion regarding being able to update the main CA trust stores within pods to include our Internal CAs.  As this clears a number of issues our internal customers see when trying to talk to internal services which use an internal CA rather than a public CA.

Another option that could work, perhaps, would be to allow us to mount a certificate into /etc/pki/ca-trust/source/anchors/mycert.crt

That way, we could at least address any applications or use cases which rely on that location for CA trusts. It wont get everything but this would cover a *lot* of situations. Since we already are able to mount things into every pod (like /var/run/secrets) I don't think this would be that big of a deal to do. Combined with a process similar to https://access.redhat.com/site/solutions/3259991 to get the secret baked into the project template, I think this might be a more feasible approach to the request.

This RFE has been moved to Jira: https://jira.coreos.com/browse/RFE-144