Add blog post for getting started with ANP #146
Conversation
k8s-ci-robot
added
do-not-merge/work-in-progress
✅ Deploy Preview for kubernetes-sigs-network-policy-api ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
k8s-ci-robot
added
approved
|
@Dyanngg: GitHub didn't allow me to request PR reviews from the following users: rahulkjoshi. Note that only kubernetes-sigs members and repo collaborators can review this PR, and authors cannot review their own PRs. In response to this: 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/test-infra repository. |
blog/Getting Started with ANP.md
Outdated
|
|
||
| 1. There are certain traffic patterns in the cluster that, as a cluster admin, I want to always allow. For example, all namespaces should allow ingress traffic from a monitoring application in the cluster for compliance reasons, and all namespaces should allow egress toward kube-dns running in the kube-system namespace. | ||
|
|
||
| 2. As a cluster admin I want to change the default security model for my cluster, so that all inter-tenant traffic (traffic between namespaces with different tenant labels) is blocked by default. Namespace owners will need to use NetworkPolicies to explicitly allow known traffic. |
There was a problem hiding this comment.
not sure if this list should cover all new objects, but should we add BANP use case here too?
There was a problem hiding this comment.
Well I'm assuming the second use case covers BANP?
There was a problem hiding this comment.
ah so second point is BANP+tenancy?
blog/Getting Started with ANP.md
Outdated
|
|
||
| - `AdminNetworkPolicy` and `BaselineAdminNetworkPolicy` are cluster-scoped resources. The subject of the policy can be the entire cluster namespaces, a select set of namespaces, or even select set of pods in a select set of namespaces, depending on the actual use of the policy. | ||
|
|
||
| - AdminNetworkPolicy rules are enforced in a hierarchical order based on priority. `AdminNetworkPolicy` objects with a smaller numerical `priority` in its spec have higher precedence over those with a larger numerical `priority`. Furthermore, rules inside a policy are enforced in the order they are written (ingress and egress rules does not have relevant order among each other though). To avoid potential conflict in rules, we generally advise against creating multiple `AdminNetworkPolicy` objects at the same `priority`. |
There was a problem hiding this comment.
does it mean we don't have validation to check there are no 2 objects with the same priority?
There was a problem hiding this comment.
No we do not have validation. It is due to the fact that there could be different ANPs in the cluster applied to entirely separate workloads and control distinct traffic patterns, but serves similar purposes so logically it makes sense to be created at the same priority.
There was a problem hiding this comment.
if policies at the same prio are applied to separate workloads, then they may have different priorities as well with the same effect right? Is it worth it risking undefined behaviour by allowing same priority ANPs in that case? (not related to this PR ofc, just wondering)
blog/Getting Started with ANP.md
Outdated
|
|
||
|  | ||
|
|
||
| 1. Traffic within the two sales tenant namespaces is allowed. Firstly, no `AdminNetworkPolicy` rule matches this type of traffic. Both tenant=sales namespaces are indeed selected by the "cluster-basic-allow" `AdminNetworkPolicy`, but the flow in question is neither going to dns components nor from the monitoring namespace. Moving further down the hierarchy, no `NetworkPolicy` can possibly be matched as well since there are none of them in the cluster currently. Finally, the "default" `BaselineAdminNetworkPolicy` is evaluated, and this traffic flow matches the first rule of the `BaselineAdminNetworkPolicy` egress section: for packets sent by the `app=db` pod towards the `app=web` pod, the first egress rule is matched from the perspective of namespace `s1`, since the rule dictates that for all namespaces any egress traffic going to namespaces with the same `tenant` label should be given the green light. The same logic applies for the reverse traffic. |
There was a problem hiding this comment.
I think it may be easier to read and understand if we go in the decreasing priority order, so that you don't need to check if there is anything with a higher prio every time, wdyt?
There was a problem hiding this comment.
Ummm I'm not too sure I follow what you mean here. In a waterfall-like priority rule evaluation model, we would need to first check the higher priority rules and move on if they don't match, right?
There was a problem hiding this comment.
yeah I mean since cluster-basic-allow is the highest priority policy, it may be easier to start with connection 3 and 4, and then you won't need Both tenant=sales namespaces are indeed selected by the "cluster-basic-allow" AdminNetworkPolicy, but the connection in question is neither going to dns components nor from the monitoring namespace. for flow 1 because we have already reviewed all higher-prio policies?
blog/Getting Started with ANP.md
Outdated
|
|
||
|  | ||
|
|
||
| On the other hand, there's a caveat that many will find surprising: traffic from `s1`, the other sales tenant namespace, will be blocked(7) when it reaches the pod in `s2`. Did we not create a baseline allow rule for each namespace in the same tenant to connect to each other? Yes we did. But as mentioned before, the AdminNetworkPolicy API does not change the behavior of NetworkPolicy objects. The `allow-access-to-web` NetworkPolicy, in this case, can be read as "all pods in s2 are isolated in the ingress direction, except for traffic from a1 which is allowed". So connections initiated from `s1` to `s2` will be dropped due to this implicit isolation effect before the `BaselineAdminNetworkPolicy` rules are even evaluated. |
There was a problem hiding this comment.
Thanks for doing this @Dyanngg Sorry for all the comments :/
I think overall I like the message and demo scenarios... but there are a few things I think we should think about:
- Do we need so much first-person
- I think we want to try a bit less detailed in some of the traffic flow descriptions as it's fairly easy to get lost with all the "as above" references etc
blog/Getting Started with ANP.md
Outdated
| traffic from `s1`. The important aspect here though, is that once a NetworkPolicy is applied | ||
| to a pod, it will control it security posture at entirety, unless a `AdminNetworkPolicy` rule | ||
| overrides it from a priority above. `BaselineAdminNetworkPolicy` rules are only effective in | ||
| the absence of those policies. |
There was a problem hiding this comment.
Maybe have a quick wrap up paragraph with details on how to get involved in the group?
|
@Dyanngg Are you ready for another pass here? |
Yep I think the vast majority of your first round comments are addressed |
|
This looks great @Dyanngg!! Please just Add it to the blog https://network-policy-api.sigs.k8s.io/blog/ by moving to https://github.com/kubernetes-sigs/network-policy-api/tree/main/site-src/blog/posts updating the index etc Otherwise it should be GTG |
blog/Getting Started with ANP.md
Outdated
| traffic (most commonly dns) when they apply NetworkPolicies. This is due to the implicit | ||
| deny nature of the NetworkPolicy semantics: pods selected by NetworkPolicies are automatically | ||
| isolated except for any ingress/egress traffic that is explicitly allowed. | ||
| So, without any admin-facing policy APIs, to "ensure" that dns always works and monitoring |
There was a problem hiding this comment.
The reader may benefit from section headers
Seems like we have:
- Problem Overview
- NetPolV1 Solution and Limitations
- Improved Solution with Admin policies
- Connectivity example with AdminNetworkPolicy
- Continued example with BaselineAdminNetworkPolicy
- Takeaways & Next Steps
Dyanngg
changed the title
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
|
@astoycos Can you check if you have any other comments that need to be addressed? Otherwise let's get our first blog on to the website :P |
|
@Dyanngg Content looks good but the blog still isn't rendering correctly I don't think :) https://deploy-preview-146--kubernetes-sigs-network-policy-api.netlify.app/blog/ |
Signed-off-by: Dyanngg <dingyang@vmware.com>
Thanks for checking Andrew!! Now it renders correctly but seems the entire blog content is on the index page. Maybe it's because there's only one blog as of now? |
Signed-off-by: astoycos <astoycos@redhat.com>
|
I fixed it @Dyanngg :) 🥳 /lgtm |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: astoycos, Dyanngg, huntergregory The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Adding the first blog post for the network-policy-api website, covering basics of AdminNetworkPolicy API usage and interoperation with NetworkPolicy