Skip to content

Commit

Permalink
Add user stories for ANP Egress Cluster control
Browse files Browse the repository at this point in the history
Signed-off-by: Surya Seetharaman <[email protected]>
  • Loading branch information
tssurya committed Mar 28, 2023
1 parent f51e7d8 commit 544d23b
Show file tree
Hide file tree
Showing 3 changed files with 97 additions and 0 deletions.
3 changes: 3 additions & 0 deletions docs/userstories/v1/egress-control-in-anp/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
# Admin Network Policy API: Northbound Traffic User Stories

This directory tracks the user stories we should cover as part of our ongoing efforts to support cluster egress traffic.
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@

### Summary

1. **As a** cluster administrator **I want** to easily block access from
cluster workloads to k8s-apiservers running on cluster nodes (host-net pods).
2. **As a** cluster administrator **I want** to easily block access from
cluster workloads to specific ports on cluster nodes.

### Description

Currently the behaviour for policies defined around traffic from cluster
workloads (non-hostNetworked pods) towards hostNetworked pods or nodes in the
cluster is undefined. See https://github.com/kubernetes-sigs/network-policy-api/issues/73.

ANP currently supports only east-west traffic and this traffic flow cuts from
overlay to underlay which makes this part of the egress (south-north) use case.

Let's provide a defined behaviour in ANP to explicitly achieve the use cases.

### Acceptance Criteria

1. If I apply a policy that limits egress access from workloads identified
by label:A towards k8s-apiserver backends (master nodes at 6443 port), it should
be able to guarantee that those workloads cannot access the apiserver
endpoints:targetPort. Even if the master node IPs change, the policy should be
able to automatically pivot towards the new nodeIPs.

[
Also, here are a few points that need to be addressed:

1. Clarify that the existing `podSelector` in the ANP API are for regular
non-hostNetworked pods only. These don't apply to hostNetworked pods.
2. Add a new well defined optional field called `hostNetworkPodSelector` to both
`Subject` and `Peer` to be able to explicitly select host networked pods.
]

### Resources:

* https://github.com/danwinship/enhancements/blob/cluster-egress-firewall/keps/sig-network/20190917-cluster-egress-firewall.md#blocking-access-to-services-used-by-the-node
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@

### Summary

1. **As a** cluster administrator **I want** to restrict traffic from
specific cluster workloads to all or specific destinations outside the
cluster **so that** I can enforce security for northbound traffic.

2. **As a** cluster administrator **I want** to explicitly allow traffic
from cluster workloads to handpicked destinations outside the cluster and
deny the rest **so that** I can guarantee cluster wide egress traffic
flow irrespective of whatever network policies are defined by the
developer for specific namespaces.

### Description

Often times cluster administrators want to explicitly control the
egress traffic from workloads towards external destinations like allowing
some (not all) workloads to access a secure service outside the cluster.

They might also want to setup cluster wide safeguard rules for egress in
general so that they don't have to worry about when namespace specific
policies are created by users at any given point.

### Acceptance Criteria

1. If I add an admin network policy to deny traffic from a specific "subject"
of workloads towards an external destination (optionally provide port
restrictions) then those workloads should not be able to connect to that
external destination.

2. If I apply an admin network policy with lower precedence egress rules to deny
traffic from a specific "subject" of workloads towards all external
destinations and then apply higher precedence egress rules to allow traffic for
those workloads towards well defined destinations then those workloads should
not be able to connect to any other external destinations than the explicitly
allowed ones.

[
Also, here are a few points that need to be addressed:

1. Addressing ingress use cases for north-south traffic is out of scope.
If we have requests from users to restrict access INTO the cluster
workloads from external entities we can consider a new `ingress-control-to-cluster`
case in the future. That will be a separate effort altogether.
2. I propose to include this in our existing ANP & BANP objects and not create
a new object.
]

### Resources:

* https://github.com/kubernetes-sigs/network-policy-api/issues/28

### Notes

* This is listed as one of the beta graduation criterias: https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/2091-admin-network-policy#alpha-to-beta-graduation. Let's try to get this in our alpha versions itself.

0 comments on commit 544d23b

Please sign in to comment.