you could also provide the /etc/pki/tls/cert.pem file(assuming it contains all your trusted CAs) via a configmap mount which would not require these permissions.

But I'm going to send this bug to the pod team for starters to see if they can offer guidance on why the selinux is preventing access to the mounted hostpath.

related:  https://bugzilla.redhat.com/show_bug.cgi?id=1592936

i was able to fix this by adjusting the context in /etc/pki on all my infra nodes.

chcon -R --type=container_t /etc/pki

Relabeling /etc/pki on the host to be container accessible is not advised for security reasons.  A bad container could write to /etc/pki on the host and get the host trust bad certs.

Thus selinux is behaving as expected blocking container access to /etc/pki on the host.

I would recommend doing what Ben recommends and mounting your CAs in from a secret, not hostPathing them from the node.  Openshift has fairly (effectively) limited support for hostPath as many parts of the host filesystem are inaccessible to containers because of selinux.

For the docker-registry, this works.  However, you do have the issue of the apiserver static pods not being able to access secrets without the apiserver already being up, so mounting them in with a secret is chicken-egg problematic.

I am not experienced enough about the recommended config for using an external CA (in this cases, self-signed) in the cluster.

Back to Image Registry for additional guidance on how this could be done in 3.10.

> Thus selinux is behaving as expected blocking container access to /etc/pki on the host.

shouldn't selinux at least allow the read?  (I don't think a write is being attempted).

What changed about v3.10 that introduced this? The apiserver being in a pod?

Was this pattern of installing custom certs in /etc/pki used in 3.9 since the apiserver ran as a host process (not in a container)?

If so, we should allow reads on cert_t from container_t and this bug should go to RHEL product container-selinux component.

Yes.  Also, the docker-registry pod(s) need access because the images are now "pulled-through" the internal registry.

The specific issue Nicholas ran into is that the imagestreams in 3.10 leverage pullthrough (in 3.9 they did not).  Pullthrough means now the internal registry is responsible for pulling the images from the external registry, instead of the host's docker daemon doing it.

That means the internal docker registry needs to be able to trust the external registry, which means including potentially self-signed certs in the docker-registry pod.  This was an issue that periodically came up before 3.10, but now that our out of box examples are using pullthrough it's a bit more likely for users to hit it (even so most users won't hit it because the imagestreams reference a trusted registry..but Nicholas has modified them to reference an untrusted registry).


The apiserver being in a pod is presenting similar problems, but it's worth noting that Nicholas did not hit any selinux problems when mounting host certs into the apiserver pod.  Only when mounting them into the docker-registry pod.

Anyway regardless of why it's coming up now and whether or not the configmap/secret mount approach is better than a hostmount, it still seems like the reads should be allowed.  And i'd like to understand why the apiserver pod is not having problems while the docker-registry pod is.  Is it related to SCCs?

It is because the apiserver pod runs as a SPC (super privileged container, type spc_t) which has read access to most everything on the host.

# ps -feZ | grep "openshift start master"
system_u:system_r:spc_t:s0      root      93131  93115  4 17:35 ?        00:00:53 openshift start master api --config=/etc/origin/master/master-config.yaml --loglevel=2
system_u:system_r:spc_t:s0      root      93355  93340  5 17:35 ?        00:01:03 openshift start master controllers --config=/etc/origin/master/master-config.yaml --listen=https://0.0.0.0:8444 --loglevel=2
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 100528 97636  0 17:55 pts/0 00:00:00 grep --color=auto openshift start master

from apiserver.yaml:

    securityContext:
      privileged: true

Created attachment 1454446 [details]
audit log

Ok, i'm going to send this to container-selinux per comment 6, in that I believe /etc/pki should always be readable (but not necessarily writable) w/o special privileges.  Thanks Seth!

Meanwhile we'll continue to work on improving the experience around providing certs to the docker-registry pod w/o using hostmounts so users can avoid this problem entirely (step 1 for that is to document how to use a configmap or secret instead).

Since RHEL7 is no longer supported, I am going to close this as WONTFIX.
The way to probably handle this is with custom policy using udica.