feat(network): enable optional egress network policy

[andrewazores]

Fixes #205
Depends on #208
Based on #208

Extends the previous Ingress policy with an Egress policy. This prevents Cryostat's Pods from opening network connections to unexpected destinations. This primarily prevents things like:

1. Administrator installs Cryostat with target namespaces A, B
2. User defines Custom Target in namespace C

or

1. Administrator installs Cryostat with target namespaces A, B
2. User defines Custom Target on the open internet

or

1. Administrator installs Cryostat with target namespaces A, B
2. Misconfigured or malicious discovery plugin registers itself and publishes a target with a callback URI in namespace C, or on the open internet

As mentioned in #208, this is an additional layer and stronger enforcement of the ideas in cryostatio/cryostat-agent#242 and cryostatio/cryostat#323 . If enabled, it also would solve the problem underlying cryostatio/cryostat#685 , though it would be even better to also solve that directly in Cryostat.

Currently, the egress policy seems to cause connections between Cryostat and its database to fail when deploying to OpenShift (crc or otherwise). I was able to test it successfully in kind v0.25.0.

1. kind create cluster
2. kubectl create namespace test
3. kubectl create namespace apps1, then used the Operator's Makefile: make sample_app. Then kubectl edit svc quarkus-test -n apps1 and renamed the 9097 port to simply jmx so that it would not be auto-discovered.
4. kubectl create namespace apps2, then spun up another sample app instance the same as above.
5. kubectl ns test, then spun up yet another sample app instance but left this one with the jfr-jmx port name.
6. helm install --set core.discovery.kubernetes.namespaces="{test,apps1}" --set networkPolicy.egress.enabled=true cryostat ./charts/cryostat and follow the post-installation steps for port-forwarding
7. Once the deployment is ready and port forwarding is active, open the URL to visit the Cryostat UI. Everything should be working as normal and the quarkus-test target in test (installation namespace) should be discovered and usable as usual. The quarkus-tests in apps1 and apps2 should not be discovered.
8. Go to the Topology > Create Custom Target view.
9. Check that localhost:0 custom target can be tested for connectivity. It should succeed.
10. Check that quarkus-test:9097 custom target connectivity test fails quickly. The UI does not properly reflect it at the moment, but the Cryostat Pod logs should show that it is refusing to define this target because it has already been discovered.
11. Check that quarkus-test.test:9097 fails. This is the same as the previous step, just explicitly specifying the namespace instead of allowing it to be implicit.
12. Check that quarkus-test.apps1:9097 succeeds. This is the sample app in apps1 with the renamed port, so it is in a target namespace but not auto-discovered. Therefore, it should be possible to define this custom target.
13. Check that quarkus-test.apps2:9097 times out and fails. This is a sample app in apps2, which is not a target namespace, therefore the cluster should deny Cryostat's connection attempt to this application's service.

To test in OpenShift, simply install with --set networkPolicy.egress.enabled=false (or leave it unset, as false is the default). This should result in the same usual behaviour since the new policy should not be created.

Testing on minikube should result in nothing really happening differently, as the default minikube network provider does not support NetworkPolicy objects. They will still be created and kubectl describe networkpolicy will explain what they are intended to do, but no actual ingress/egress restrictions will occur.

[tthvo]

Since #208 got merged, let's review this too?

[andrewazores]

This will have a conflict with #247, depending on which one gets merged first - the egress policy will need to be automatically adjusted to allow Cryostat to open outgoing connections to the external S3 provider, if any.

[andrewazores]

https://kubernetes.io/docs/concepts/services-networking/network-policies/

I'm actually not sure if there is a way to create an egress policy which allows for outbound connections to an external service. Users may simply need to leave egress policies disabled if they are using an external S3 provider.

[ebaron]

I'm having a bit of trouble on a Kind cluster following the instructions. The sample app in the "test" namespace appears, and I can receive MBean metrics from it, but when trying to create a recording, I get a 504 Gateway Timeout when hitting the "Create" button.

127.0.0.1:58666 - 6287c32c-501f-4b02-a1b1-11a78abc69ca - - [2025/10/15 19:37:20] localhost:8080 POST cryostat "/api/v4/targets/1/recordings" HTTP/1.1 "Mozilla/5.0 (X11; Linux x86_64; rv:143.0) Gecko/20100101 Firefox/143.0" 504 0 30.585

Here's the Egress policy created:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  annotations:
    meta.helm.sh/release-name: cryostat
    meta.helm.sh/release-namespace: test
  creationTimestamp: "2025-10-15T19:32:37Z"
  generation: 1
  labels:
    app.kubernetes.io/managed-by: Helm
  name: cryostat-internal-egress
  namespace: test
  resourceVersion: "1133"
  uid: 90c679cb-4325-42e0-b4da-9add847bcc01
spec:
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
  - to:
    - namespaceSelector:
        matchExpressions:
        - key: kubernetes.io/metadata.name
          operator: In
          values:
          - test
          - test
          - apps1
  podSelector:
    matchLabels:
      app.kubernetes.io/component: cryostat
      app.kubernetes.io/instance: cryostat
      app.kubernetes.io/name: cryostat
      app.kubernetes.io/part-of: cryostat
  policyTypes:
  - Egress

[andrewazores]

Hmm, it's working as expected for me still after following the same steps I outlined. I'm also not sure how it could be that Cryostat is able to connect to the target to pull MBean metrics, but unable to connect in order to start a recording since it should be the same kind of connection either way. Could the 504 be coming from something else, like ex. an external storage provider configuration that is failing?

[ebaron]

Hmm, it's working as expected for me still after following the same steps I outlined. I'm also not sure how it could be that Cryostat is able to connect to the target to pull MBean metrics, but unable to connect in order to start a recording since it should be the same kind of connection either way. Could the 504 be coming from something else, like ex. an external storage provider configuration that is failing?

Yeah maybe an issue with my Kind. I deleted the egress network policy and it's still giving me timeouts.