An admin jump tool Pod should accept SSH-like traffic on TCP 2222 only from the trusted CIDR 203.0.113.0/24. Which NetworkPolicy peer fits that ingress allow?
Select an answer to reveal the explanation.
Short Explanation
You want a velvet rope that only the trusted street range can pass—and only on the jump port. That’s an ingress ipBlock for 203.0.113.0/24 on TCP 2222 aimed at the jump Pod. Opening the world and excepting the trusted range would do the opposite.
Full Explanation
An admin jump tool Pod that should accept SSH-like traffic on TCP 2222 only from trusted CIDR 203.0.113.0/24 needs an ingress allow from ipBlock cidr 203.0.113.0/24 on TCP port 2222 to the Pods selected by the policy. That is a velvet rope admitting only the trusted street range—and only on the jump port—toward the selected municipal admin Pod. ipBlock is the NetworkPolicy peer type designed for external CIDR sources.
An egress rule to a podSelector matching the jump Pod on UDP 2222 is the wrong direction and wrong protocol for an ingress SSH-like allow. Ingress from a namespaceSelector matching kube-system only on any port does not express the trusted CIDR requirement and over-allows cluster DNS/system namespaces. Ingress from ipBlock 0.0.0.0/0 with except 203.0.113.0/24 inverts the intent by allowing the world minus the trusted range—exactly the opposite velvet rope.
Exam caveat: pair ipBlock with explicit protocol and port; direction must be ingress when the jump Pod is the protected destination. Operational check: connect from an address inside 203.0.113.0/24 to TCP 2222 and succeed; connect from outside the CIDR and fail; kubectl describe networkpolicy and show the ipBlock to city jump-host auditors. Keep the trusted CIDR inventory under change control so exceptions are reviewed like firewall tickets.