[Request] Reports sidecars should be secured

[andrewazores]

Describe the feature

When the Cryostat CR contains configuration to deploy Reports sidecars, the Operator should also place an auth proxy instance in front of these Pods. The Operator can generate a basic auth secret for this auth proxy to exclusively use, and can reconfigure the Cryostat container's reports service URL to include the basic auth credentials. This way the reports sidecar is not accessible by other processes within the cluster that can see its Service, but only by the Cryostat instance associated with the same CR.

Anything other information?

No response

[andrewazores]

Another possibility instead of using an auth proxy and generated basic auth could be to use mutual TLS.

[andrewazores]

Another option is to leave off the TLS and authentication and rely simply on a network policy to restrict allowed traffic to the reports Service to only requests originating from the Cryostat Pod(s). This is probably the simplest option.

Ideally, we have a network policy plus mTLS, or policy + TLS + auth.

[tthvo]

Another option is to leave off the TLS and authentication and rely simply on a network policy to restrict allowed traffic to the reports Service to only requests originating from the Cryostat Pod(s). This is probably the simplest option.

This does mean that the k8s cluster must have a network plugin that supports Network Policies. I think kindnet shipped with KinD does not support it yet: https://github.com/kubernetes-sigs/kind/issues/842 so we might need to consider other alternatives for CI/dev environment.

May I help with this if no one has already started it?

[andrewazores]

I don't think anyone has started on this, though @mwangggg is working on #814 which might have some slight overlap in areas, since once those other containers are split out to separate Deployments (the same way -reports is) they will have the some concerns about access and security.

What happens if the cluster network plugin doesn't support these policies? If they just get ignored or emit a warning and proceed without the restriction then I think that would be fine. Otherwise, we might need to add some kind of capability test in the Operator controller before adding the configuration, if possible.

[andrewazores]

Creating a NetworkPolicy resource without a controller that implements it will have no effect.

Sounds promising that it should be simple to add this as an enhancement, which will just be ignored if it isn't supported on the particular cluster. This does mean we should not rely on this alone, but it's a cheap and easy piece of additional security where it is supported.

[tthvo]

I don't think anyone has started on this, though @mwangggg is working on https://github.com/cryostatio/cryostat-operator/issues/814 which might have some slight overlap in areas, since once those other containers are split out to separate Deployments (the same way -reports is) they will have the some concerns about access and security.

Ah right, I will leave it to @mwangggg then.

Creating a NetworkPolicy resource without a controller that implements it will have no effect.

Sounds promising that it should be simple to add this as an enhancement, which will just be ignored if it isn't supported on the particular cluster. This does mean we should not rely on this alone, but it's a cheap and easy piece of additional security where it is supported.

Yehh, it should fall into the same case with Ingress objects that requires an Ingress Controller. We can document and suggest the users with appropriate plugins (e.g. Calico, Cilium). I think on OpenShift side, that should be fine.