<p>I have the following network policy for restricting access to a frontend service page: </p>

<pre><code>apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  namespace: namespace-a
  name: allow-frontend-access-from-external-ip
spec:
  podSelector:
    matchLabels:
      app: frontend-service
  ingress:
    - from:
        - ipBlock:
            cidr: 0.0.0.0/0
        ports:
          - protocol: TCP
            port: 443
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
        ports:
          - protocol: TCP
            port: 443
</code></pre>

<p>My question is: can I enforce HTTPS with my egress rule (port restriction on 443) and if so, how does this work? Assuming a client connects to the frontend-service, the client chooses a random port on his machine for this connection, how does Kubernetes know about that port, or is there a kind of port mapping in the cluster so the traffic back to the client is on port 443 and gets mapped back to the clients original port when leaving the cluster?</p>

ItFreak
<p>You might have a wrong understanding of the network policy(NP). </p>

<p>This is how you should interpret this section:</p>

<pre><code>egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
        ports:
          - protocol: TCP
            port: 443
</code></pre>

<p>Open port <code>443</code> for outgoing traffic for all pods within <code>0.0.0.0/0</code> cidr.  </p>

<p>The thing you are asking </p>

<blockquote>
  <p>how does Kubernetes know about that port, or is there a kind of port
  mapping in the cluster so the traffic back to the client is on port
  443 and gets mapped back to the clients original port when leaving the
  cluster?</p>
</blockquote>

<p>is managed by kube-proxy in following way:</p>

<p>For the traffic that goes from pod to external addresses, Kubernetes simply uses SNAT. What it does is replace the pod’s internal source IP:port with the host’s IP:port. When the return packet comes back to the host, it rewrites the pod’s IP:port as the destination and sends it back to the original pod. The whole process is transparent to the original pod, who doesn’t know the address translation at all.</p>

<p>Take a look at <a href="https://kubernetes.io/blog/2019/03/29/kube-proxy-subtleties-debugging-an-intermittent-connection-reset/" rel="nofollow noreferrer">Kubernetes networking basics</a> for a better understanding. </p>
