-
Notifications
You must be signed in to change notification settings - Fork 151
CCO-681: Add network policies with default deny #871
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
This change adds the network policies necessary to maintain functionality of the operator while enforcing a default deny for ingress and egress traffic. It provides the following: Default deny all ingress and egress Allow egress from cloud-credential-operator to kube api Allow egress from cloud-credential-operator to DNS Allow egress from cloud-credential-operator to external cloud platforms Allow egress from pod-identity-webhook to DNS Allow egress from pod-identity-webhook to external cloud platforms Allow ingress to cloud-credential-operator:8443 (metrics) Allow ingress to cloud-credential-operator:6060 (pprof) Allow ingress to pod-identity-webhook:9443 (webhook)
@jstuever: This pull request references CCO-681 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
/hold |
/test list |
@jstuever: The specified target(s) for
The following commands are available to trigger optional jobs:
Use
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
/test e2e-azure e2e-gcp e2e-openstack |
/test e2e-aws-manual-oidc e2e-azure-manual-oidc e2e-gcp-manual-oidc |
include.release.openshift.io/self-managed-high-availability: "true" | ||
spec: | ||
egress: | ||
- ports: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this a large range? You know the ports that you want to allow traffic to... check out the example ones in: https://docs.google.com/document/d/1CDoGSRd-h8VT4PMrK_83Ro0YzYPjORbkxtfTJU1sN6Q/edit?tab=t.0#heading=h.atjxybk6bxes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because there is a use case where a user can specify the cloud api endpoint and we have no guarantee that it is limited to ports 80/443.
/retest |
@jstuever: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
/assign @dlom |
/cc @huangmingxia |
Looks very similar to what we discussed last thursday /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dlom, jstuever 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:
Approvers can indicate their approval by writing |
Hi @jstuever I’ve performed some tests on the AWS STS cluster, and the results are recorded in test case OCP-82633. When you have time, could you please help review it? Thanks. I’ll proceed with testing on other platforms next. Also, I noticed the following statement in the enhancements documentation:
I’m not entirely sure if this requires any additional handling on our side during testing or implementation. Could you please help confirm whether we need to pay special attention to this? Thanks :) |
@huangmingxia Test case OCP-82633 looks good to me for the AWS platform. It is my understanding that the "namespace admission controller" requirements are outside the scope of the cloud credential operator epic. I believe the intent is to have the namespace admission controller label all of the openshift namespaces in order to facilitate a cluster-wide administrative network policy that will explicitly deny all ingress/egress traffic in all of the labelled openshift namespaces. This epic is focused on the effort of ensuring cloud-credential-operator has all of the required network policies to continue functioning after that cluster-wide policy is applied (at a later date). |
This change adds the network policies necessary to maintain functionality of the operator while enforcing a default deny for ingress and egress traffic. It provides the following:
Default deny all ingress and egress
Allow egress from cloud-credential-operator to kube api
Allow egress from cloud-credential-operator to DNS
Allow egress from cloud-credential-operator to external cloud platforms
Allow egress from pod-identity-webhook to DNS
Allow egress from pod-identity-webhook to external cloud platforms
Allow ingress to cloud-credential-operator:8443 (metrics)
Allow ingress to cloud-credential-operator:6060 (pprof)
Allow ingress to pod-identity-webhook:9443 (webhook)