Restrict webhook access to kube-system API server

[ViciousEagle03]

Pull Request Template for Kubeflow Manifests

✏️ Summary of Changes

Modified the below files in the common/networkpolicies/base directory

• kserve.yaml
• pvcviewer-webhook.yaml
• spark-operator-webhook.yaml
• training-operator-webhook.yaml

Added the necessary restriction to allow access only from the apiserver namespace kube-system for webhooks.

Fixed YAML indentation issues that were previously undetected, as the workflow was not triggered on commits modifying the kserve.yaml, pvcviewer-webhook.yaml file.

📦 Dependencies

List any dependencies or related PRs (e.g., "Depends on #123").

🐛 Related Issues

• Fixes Stricter networkpolicies #2928

✅ Contributor Checklist

• I have tested these changes with kustomize. See Installation Prerequisites.
• All commits are signed-off to satisfy the DCO check.

---

You can join the CNCF Slack and access our meetings at the Kubeflow Community website. Our channel on the CNCF Slack is here #kubeflow-platform.

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign juliusvonkohout for approval. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• common/networkpolicies/OWNERS

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

[ViciousEagle03]

Since we have added the restriction, do we want the comments to be updated here?

[juliusvonkohout]

What do you suggest?

[juliusvonkohout]

Thank you for the PR. Do you know whether

  - from:
    - podSelector:
        matchLabels:
          component: kube-apiserver
      namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system

works for all popular clusters, so AKS, EKS, GKE, KIND; MINIKUBE; Rancher ?

[ViciousEagle03]

@juliusvonkohout So I did some research on locally hosted and managed clusters(GKE, AKS, EKS...) like the one you listed above, but I couldn't find any clear issues with the above approach. Are you suggesting using matchExpressions for more flexibility instead of matchLabels, or are you recommending exposing the entire namespace rather than targeting the specific API server? I'm a bit lost, could you point me in the right direction?

Edit: Also, I will add the restriction to the other network policies once we finalize the implementation to enforce the restrictions.

[juliusvonkohout]

@juliusvonkohout So I did some research on locally hosted and managed clusters(GKE, AKS, EKS...) like the one you listed above, but I couldn't find any clear issues with the above approach. Are you suggesting using matchExpressions for more flexibility instead of matchLabels, or are you recommending exposing the entire namespace rather than targeting the specific API server? I'm a bit lost, could you point me in the right direction?

Edit: Also, I will add the restriction to the other network policies once we finalize the implementation to enforce the restrictions.

I would just like to get this tested on GKE, AKS, EKS and rancher before we merge it.

@tarekabouzeid @varodrig can you help with that?

[varodrig]

o get this tested on GKE, AKS, EKS and rancher before we merge it.

can we include OpenShift as well?

[juliusvonkohout]

o get this tested on GKE, AKS, EKS and rancher before we merge it.

can we include OpenShift as well?

Yes, please test on what you have available and report back.

[juliusvonkohout]

@ViciousEagle03 sorry for the delay. it might be that we only merge this after the 1.10.0 release.

[juliusvonkohout]

I am just waiting for test feedback to merge this.