Skip to content
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

missing dash before ports #50012

Open
cindyhu-gd opened this issue Mar 5, 2025 · 5 comments
Open

missing dash before ports #50012

cindyhu-gd opened this issue Mar 5, 2025 · 5 comments
Labels
needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done.

Comments

@cindyhu-gd
Copy link

When allow outgoing DNS traffic on port 53 TCP and UDP, a dash character should be placed before ports, see below snippet, otherwise, it won't take effect.

For example, without dash in front of ports, DNS name like microservice1.space2.svc.cluster.local cannot be resolved.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: np
namespace: space1
spec:
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: space2
  - ports:
    - port: 53
      protocol: TCP
    - port: 53
      protocol: UDP
  podSelector: {}
  policyTypes:
  - Egress
@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Mar 5, 2025
@k8s-ci-robot
Copy link
Contributor

This issue is currently awaiting triage.

SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

@sftim
Copy link
Contributor

sftim commented Mar 5, 2025

I don't think this issue is correct. Maybe we should use an different example policy, but the change you're proposing looks like the wrong fix.

/priority awaiting-more-evidence

@k8s-ci-robot k8s-ci-robot added the priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. label Mar 5, 2025
@sftim
Copy link
Contributor

sftim commented Mar 5, 2025

I think maybe we shouldn't use port 53 UDP as an example. People are liable to try adapting this, and may then wonder why DNS doesn't work in that namespace.

@cindyhu-gd
Copy link
Author

cindyhu-gd commented Mar 6, 2025

check out the "NetworkPolicy Namespace Selector" scenario from https://killercoda.com/killer-shell-cka/scenario/networkpolicy-namespace-communication
The example on the official doc is misleading ... that's all i'm saying...
https://kubernetes.io/docs/concepts/services-networking/network-policies/

@utkarsh-singh1
Copy link
Contributor

@cindyhu-gd, are you talking about this example from here -

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done.
Projects
None yet
Development

No branches or pull requests

4 participants