generated from kubernetes/kubernetes-template-project
-
Notifications
You must be signed in to change notification settings - Fork 34
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add user stories for ANP Egress Cluster control
Signed-off-by: Surya Seetharaman <[email protected]>
- Loading branch information
Showing
3 changed files
with
97 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. |
39 changes: 39 additions & 0 deletions
39
docs/userstories/v1/egress-control-in-anp/egress-control-cluster-nodes.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 |
55 changes: 55 additions & 0 deletions
55
docs/userstories/v1/egress-control-in-anp/egress-control-outside-cluster.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. |