Added MLMD GRPC Server Network Policy

[VaniHaripriya]

The issue resolved by this Pull Request:

Resolves RHOAIENG-10994

Description of your changes:

Added a network policy for MLMD GRPC Server.

Testing instructions

• Deploy DSPO, create a dspa instance and verify if a network policy gets created for GRPC , eg. ds-pipeline-metadata-grpc-myproject.
• Create a pipeline run to verify if it works properly.
• Execute the below curl command from ds-pipeline-metadata-envoy-sample-myproject , it should connect successfully.
  curl -v ds-pipeline-metadata-grpc-myproject.<namespace>.svc.cluster.local:8080
• Execution of the same curl command from any other pod other than ds-pipeline-metadata-grpc or the driver/launcher pods should time out.

Checklist

• The commits are squashed in a cohesive manner and have meaningful messages.
• Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
• The developer has manually tested the changes and verified that the changes work

[dsp-developers]

Change to PR detected. A new PR build was completed.
A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-686

[DharmitD]

should we add these ports to ingress too maybe? https://github.com/opendatahub-io/data-science-pipelines-operator/blob/main/config/internal/ml-metadata/metadata-envoy.service.yaml.tmpl#L12
Looks like the envoy and other mlmd services are utilizing them.

[gregsheremeta]

Nope. We have these two flows:

stuff --1--> envoy --2--> mlmd
stuff --3--> mlmd

Things that connect to envoy (arrow 1) need to connect on those two ports you linked to.
Envoy itself only needs to connect to 8080 on mlmd (arrow 2).
Things that connect to mlmd directly only need to connect to 8080 on mlmd (arrow 3).

Arrows 2 and 3 are the ones we care about in this NetworkPolicy, so 8080 is all we need.

[HumairAK]

this is not needed, by default if no namespaceSelector is provided, pods in the policy's own namespace are selected :

If NamespaceSelector is also set, then the NetworkPolicyPeer as a whole selects the Pods matching PodSelector in the Namespaces selected by NamespaceSelector. Otherwise it selects the Pods matching PodSelector in the policy's own Namespace. [1]

[HumairAK]

I don't think the testing instructions are sufficient. We need to also verify that pods not selected are denied access. This verification may require you to provide a pod from which you can connect to the mlmd grpc service via cli in some way

[VaniHaripriya]

I don't think the testing instructions are sufficient. We need to also verify that pods not selected are denied access. This verification may require you to provide a pod from which you can connect to the mlmd grpc service via cli in some way

Updated the testing instructions, please check.

[dsp-developers]

Change to PR detected. A new PR build was completed.
A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-686

[dsp-developers]

Change to PR detected. A new PR build was completed.
A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-686

[gregsheremeta]

/verified

deployed dspo from main. created a dspa in project dspa1.

created a new project called "ubi". created this pod in there:

apiVersion: v1
kind: Pod
metadata:
  name: ubi9-pod
  labels:
    app: ubi9
spec:
  containers:
  - name: ubi9-container
    image: registry.access.redhat.com/ubi9/ubi:latest
    command: ["sleep", "infinity"]
    tty: true

shell to the pod

$ oc rsh ubi9-pod

connect to mlmd pod that's in my dspa1 project

sh-5.1# 
sh-5.1# curl -v 10.131.14.86:8080
*   Trying 10.131.14.86:8080...
* Connected to 10.131.14.86 (10.131.14.86) port 8080 (#0)
> GET / HTTP/1.1
> Host: 10.131.14.86:8080
> User-Agent: curl/7.76.1
> Accept: */*
> 
* Received HTTP/0.9 when not allowed
* Closing connection 0
curl: (1) Received HTTP/0.9 when not allowed

works as expected (it shouldn't work ... it's what we're fixing in this PR :))

checked out this PR and redeployed dspo

created a new dspa in project dspa2.

note i see this new NetworkPolicy that wasn't in dspa1:

connect to mlmd in dspa2:

sh-5.1# curl -v 10.131.14.116:8080
*   Trying 10.131.14.116:8080...
^C
sh-5.1# 

times out as expected

pipelines run in dspa2 just fine.

great!

[gregsheremeta]

/lgtm

[HumairAK]

perfect, thanks @VaniHaripriya!

/lgtm
/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: HumairAK

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [HumairAK]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment