Yes, that fixed it for me, though I had to use single quotes around the regular expression to prevent the shell from looking inside. Should I add a comment with this workaround on the bug or is there a better place?
On 09/08/2016 11:25 AM, Seth Jennings wrote: > Hey Jonathan, > > Yes this is an issue. > > kube mounts /etc/hosts into the container from something like: > > /var/lib/kubelet/pods/9679b088-75d6-11e6-9f2b-fa163eebc035/etc-host > > on the host. That file is currently labeled with docker_var_lib_t: > > # ls -alZ etc-hosts > -rw-r--r--. root root system_u:object_r:docker_var_lib_t:s0 etc-hosts > > This should be resolved by this yet-to-be-released fix to selinux-policy: > > https://bugzilla.redhat.com/show_bug.cgi?id=1369159 > > Should be fixed in selinux-policy > 3.13.1-95.el7. > > In the meantime, you can override the selinux policy on your system manually: > > # semanage fcontext -l | grep kubelet > /var/lib/kubelet(/.*)? all files > system_u:object_r:docker_var_lib_t:s0 > > # semanage fcontext -a -t svirt_sandbox_file_t "/var/lib/kubelet(/.*)?" > > # restorecon -Rv /var/lib/kubelet > > Hope this helps! > > Seth > > On Sun, Sep 4, 2016 at 8:15 PM, Jonathan Rogers > <[email protected]> wrote: >> I'm using CentOS Atomic Host 7. I can run Docker containers directly and >> they function as expected. I set up a small Kubernetes cluster using the >> Atomic and Kubernetes documentation. I can also run containers using >> Kubernetes, but /etc/hosts is unreadable in the containers because of >> SELinux configuration. I found this be true in containers based on both >> the "busybox" Docker image as well as my CentOS 6-based image. >> >> I see that Kubernetes sets up a mount just for /etc/hosts, overriding >> Docker's default behavior. Why is this necessary? It seems that >> Kubernetes fails to apply the necessary label(s) to the hosts file it >> provides. If I use the chcon command on the host to add >> "svirt_sandbox_file_t" to the Kubernetes-managed hosts file, the >> container can read it via /etc/hosts. Of course, disabling SELinux >> enforcement also avoids the problem. >> >> Since this doesn't seem to be a common problem, I can't tell if it's >> Kubernetes, CentOS or Atomic at fault. I found a long discussion about >> SELinux vs Kubernetes which seems related. However, the Docker volume in >> question was generated automatically by Kubernetes without any explicit >> configuration. >> >> https://github.com/projectatomic/adb-atomic-developer-bundle/issues/117 >> >> -- >> Jonathan Rogers >> Socialserve.com by Emphasys Software >> [email protected] >> >> > -- Jonathan Rogers Socialserve.com by Emphasys Software [email protected]
