[Task] Place auth-proxy in front of split storage and database deployments

[andrewazores]

See https://github.com/cryostatio/cryostat-operator/wiki/Security-and-Authz#scenario , #114

[andrewazores]

cryostat-db should also be placed into its own Deployment with its own auth proxy.

Need to determine what that means for auth. The db, and for now the storage, should only be accessible by Cryostat. This can be done with a network policy restricting traffic only to the one Cryostat instance in the same namespace, but should also be done at the auth level. In the OpenShift case, would Cryostat just use its own k8s serviceaccount token? In the oauth2_proxy case would we generate an htpasswd and use Basic auth?

[andrewazores]

Both the Storage and DB containers are already set up with simple authentication using generated Secrets. Adding an oauth2 proxy in Basic mode in front to enforce authentication doesn't seem like it adds anything new. Using the OpenShift oauth proxy in front to use the Cryostat serviceaccount instead of generated credentials might be nice, but probably only works for the HTTP-based Storage and adds a hard dependency on OpenShift.

Using kube-rbac-proxy instead for authentication and k8s serviceaccount authorization would be nice, but this also seems like it likely only works for HTTP-based storage and not the JDBC database. Also, kube-rbac-proxy requires TLS configuration, so this would mean either we require the user to supply TLS configuration via Secrets, or else we have to add a dependency on something like cert-manager to automate this.

Related: #168

[andrewazores]

There are actually TLS-related Helm functions available:

https://helm.sh/docs/chart_template_guide/function_list/#cryptographic-and-security-functions

These look like a reasonable alternative to cert-manager for the Helm chart's purposes.

[andrewazores]

Closing - the remaining viable ideas here are a duplicate of #168.