Hi Marc, I'll leave the discussion to guys with more knowledge than me, but using a sidecar container to provide network storage client seems overkill or more complicated than required to me. Network storage should be managed by the node, and containers should get the mount points without caring about the filesystem type. Only the nodes (or the privileged container that manages cifs on the node, for all containers/pods in that node) should need the keytab. I'd try providing that file to the privileged pod as a configmap.
[]s, Fernando Lozano On Fri, Jun 14, 2019 at 11:21 AM Marc Boorshtein <[email protected]> wrote: > >> >> If they are not, you'll need a privileged container to work as the cifs >> client. It would be managed my a DaemonSet and probably require a custom >> SCC to grant it the necessary rights, but it is doable to have a container >> that loads kernel modules into the host and etc. >> >>> >>> > So we already have a mature way to inject a sidecar into pods that need > keytab access. We detect an annotation on an admission controller webhook > and inject a privileged pod that creates a keyring from the keystore and > shares it with the primary pod via shared memory. I think ideally what i'd > like to do is create a similar sidecar that gets the keytab from either a > secret or likely a secret manage like vault, run the mount inside of the > container then share the mount across to the primary pod. We alraedy have > a way of generating the keyring and custom sccs for each user. i figure > thats the hardest part would be sharing the mount from the sidecar to the > primary pod. Is that possible? >
_______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
