use of X509 authn (grid-security CAs and vomsdir)
If I understand correctly (e.g. from https://indico.cern.ch/event/985953/contributions/4238594/), the use of grid certificates for HTTPS and xrootd in EOS requires some additional configuration and files not in the helm chart yet. The helm chart would need to add support for:
- providing the standard CA certificate bundle (ca-policy-egi-core) in /etc/grid-security/certificates
- possibly configurable in the case of HTTPS?
EOS_FST_HTTPS_X509_CERTIFICATE_PATH
?
- possibly configurable in the case of HTTPS?
- likewise for vomsdir - at least I hope VOMS mapping is possible instead of grid mapping
I can think of a few different options for providing the CA bundle:
- Mount /cvmfs/grid.cern.ch/etc/grid-security/ either via CVMFS CSI or (in our case) hostPath from the kubelet nodes. This is the simplest way ("CAs as a service") but introduces a dependency of EOS on CVMFS which might be undesirable.
- Traditional server-style way - install the CA RPM bundle in the container image, run fetch-crl (perhaps in side-car pods). Also requires ongoing updates of the CA RPM packages. This provides independence, but requires a lot of extra instrumentation and duplication in all the pods.
- Kubernetes-style way - have a k8s cron job that both installs/updates the CA bundle as an RPM, and runs fetch-crl. It would write updates to a /etc/grid-security/ PVC which supports multiple readers but only one writer (in practice this means ReadWriteMany), backed by a PV on a shared filesystem. Then every EOS pod could mount /etc/grid-security/ read-only from that PVC.
I think I'm leaning towards option 3 but it depends which EOS pods require this (just MGM or FSTs too?)
If we don't get vomsdir from /cvmfs/grid.cern.ch/etc/grid-security/ , it could be simply a user-configurable configmap (only a few files per VO), or I think there are WLCG RPMs providing the vomsdir files for selected VOs.
@ebocchi what do you think?