Merge pull request #194 from tssurya/update-to-1.29

Update dependencies to 0.29 && Update KIND in CI to create 1.29 Kube cluster

go.mod

@@ -1,71 +1,73 @@
 module sigs.k8s.io/network-policy-api
 
-go 1.20
+go 1.21
 
 require (
 	github.com/ahmetb/gen-crd-api-reference-docs v0.3.0
-	github.com/stretchr/testify v1.8.2
-	k8s.io/api v0.28.1
-	k8s.io/apiextensions-apiserver v0.28.0
-	k8s.io/apimachinery v0.28.2
-	k8s.io/client-go v0.28.1
-	k8s.io/code-generator v0.28.0
-	sigs.k8s.io/controller-runtime v0.14.6
-	sigs.k8s.io/controller-tools v0.13.0
-	sigs.k8s.io/yaml v1.3.0
+	github.com/stretchr/testify v1.8.4
+	k8s.io/api v0.29.2
+	k8s.io/apiextensions-apiserver v0.29.2
+	k8s.io/apimachinery v0.29.2
+	k8s.io/client-go v0.29.2
+	k8s.io/code-generator v0.29.2
+	sigs.k8s.io/controller-runtime v0.17.0
+	sigs.k8s.io/controller-tools v0.14.0
+	sigs.k8s.io/yaml v1.4.0
 )
 
 require (
 	github.com/davecgh/go-spew v1.1.1 // indirect
-	github.com/emicklei/go-restful/v3 v3.9.0 // indirect
+	github.com/emicklei/go-restful/v3 v3.11.0 // indirect
 	github.com/evanphx/json-patch v5.6.0+incompatible // indirect
-	github.com/evanphx/json-patch/v5 v5.6.0 // indirect
-	github.com/fatih/color v1.15.0 // indirect
-	github.com/go-logr/logr v1.2.4 // indirect
+	github.com/evanphx/json-patch/v5 v5.8.0 // indirect
+	github.com/fatih/color v1.16.0 // indirect
+	github.com/go-logr/logr v1.4.1 // indirect
 	github.com/go-openapi/jsonpointer v0.19.6 // indirect
 	github.com/go-openapi/jsonreference v0.20.2 // indirect
 	github.com/go-openapi/swag v0.22.3 // indirect
 	github.com/gobuffalo/flect v1.0.2 // indirect
 	github.com/gogo/protobuf v1.3.2 // indirect
 	github.com/golang/protobuf v1.5.3 // indirect
 	github.com/google/gnostic-models v0.6.8 // indirect
-	github.com/google/go-cmp v0.5.9 // indirect
+	github.com/google/go-cmp v0.6.0 // indirect
 	github.com/google/gofuzz v1.2.0 // indirect
 	github.com/google/uuid v1.3.0 // indirect
+	github.com/gorilla/websocket v1.5.0 // indirect
 	github.com/imdario/mergo v0.3.6 // indirect
 	github.com/inconshreveable/mousetrap v1.1.0 // indirect
 	github.com/josharian/intern v1.0.0 // indirect
 	github.com/json-iterator/go v1.1.12 // indirect
 	github.com/mailru/easyjson v0.7.7 // indirect
 	github.com/mattn/go-colorable v0.1.13 // indirect
-	github.com/mattn/go-isatty v0.0.17 // indirect
+	github.com/mattn/go-isatty v0.0.20 // indirect
 	github.com/moby/spdystream v0.2.0 // indirect
 	github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd // indirect
 	github.com/modern-go/reflect2 v1.0.2 // indirect
 	github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822 // indirect
+	github.com/mxk/go-flowrate v0.0.0-20140419014527-cca7078d478f // indirect
 	github.com/pkg/errors v0.9.1 // indirect
 	github.com/pmezard/go-difflib v1.0.0 // indirect
 	github.com/russross/blackfriday/v2 v2.1.0 // indirect
-	github.com/spf13/cobra v1.7.0 // indirect
+	github.com/spf13/cobra v1.8.0 // indirect
 	github.com/spf13/pflag v1.0.5 // indirect
 	golang.org/x/mod v0.14.0 // indirect
 	golang.org/x/net v0.20.0 // indirect
-	golang.org/x/oauth2 v0.8.0 // indirect
+	golang.org/x/oauth2 v0.12.0 // indirect
 	golang.org/x/sys v0.16.0 // indirect
 	golang.org/x/term v0.16.0 // indirect
 	golang.org/x/text v0.14.0 // indirect
 	golang.org/x/time v0.3.0 // indirect
 	golang.org/x/tools v0.17.0 // indirect
 	google.golang.org/appengine v1.6.7 // indirect
-	google.golang.org/protobuf v1.30.0 // indirect
+	google.golang.org/protobuf v1.31.0 // indirect
 	gopkg.in/inf.v0 v0.9.1 // indirect
 	gopkg.in/yaml.v2 v2.4.0 // indirect
 	gopkg.in/yaml.v3 v3.0.1 // indirect
-	k8s.io/gengo v0.0.0-20220902162205-c0856e24416d // indirect
+	k8s.io/gengo v0.0.0-20230829151522-9cce18d56c01 // indirect
 	k8s.io/klog v0.2.0 // indirect
-	k8s.io/klog/v2 v2.100.1 // indirect
-	k8s.io/kube-openapi v0.0.0-20230717233707-2695361300d9 // indirect
-	k8s.io/utils v0.0.0-20230406110748-d93618cff8a2 // indirect
+	k8s.io/klog/v2 v2.110.1 // indirect
+	k8s.io/kube-openapi v0.0.0-20231010175941-2dd684a91f00 // indirect
+	k8s.io/utils v0.0.0-20230726121419-3b25d923346b // indirect
 	sigs.k8s.io/json v0.0.0-20221116044647-bc3834ca7abd // indirect
-	sigs.k8s.io/structured-merge-diff/v4 v4.2.3 // indirect
+	sigs.k8s.io/structured-merge-diff/v4 v4.4.1 // indirect
 )

hack/crd-e2e.sh

@@ -46,7 +46,7 @@ trap cleanup INT TERM
 res=0
 
 # Install kind
-(go install sigs.k8s.io/kind@v0.17.0) || res=$?
+(go install sigs.k8s.io/kind@v0.22.0) || res=$?
 
 # Create cluster
 KIND_CREATE_ATTEMPTED=true

mkdocs.yml

@@ -35,8 +35,8 @@ markdown_extensions:
   - admonition
   - meta
   - pymdownx.emoji:
-      emoji_index: !!python/name:materialx.emoji.twemoji
-      emoji_generator: !!python/name:materialx.emoji.to_svg
+      emoji_index: !!python/name:material.extensions.emoji.twemoji
+      emoji_generator: !!python/name:material.extensions.emoji.to_svg
   - pymdownx.details
   - pymdownx.highlight
   - pymdownx.inlinehilite

netlify.toml

@@ -2,7 +2,9 @@
 [build]
     command = "make docs"
     publish = "site"
-    environment = { PYTHON_VERSION = "3.8" }
+[build.environment]
+    PYTHON_VERSION = "3.8"
+    GO_VERSION = "1.21.4"
 
 # Standard Netlify redirects
 [[redirects]]

requirements.txt

@@ -6,14 +6,14 @@ livereload==2.6.1
 Markdown==3.3.4
 MarkupSafe==2.1.3
 mkdocs==1.5.2
-mkdocs-awesome-pages-plugin==2.7.0
-mkdocs-macros-plugin==0.6.0
-mkdocs-material==9.2.0b3
-mkdocs-material-extensions==1.1.1
+mkdocs-awesome-pages-plugin==2.9.2
+mkdocs-macros-plugin==1.0.5
+mkdocs-material==9.5.9
+mkdocs-material-extensions==1.3.1
 mike==1.1.2
-pep562==1.0
-Pygments==2.14.0
-pymdown-extensions==9.9.1
-PyYAML==5.3
-six==1.14.0
-tornado==6.0.3
+pep562==1.1
+Pygments==2.17.2
+pymdown-extensions==10.7
+PyYAML==6.0.1
+six==1.16.0
+tornado==6.4

site-src/blog/.authors.yml

@@ -1,8 +1,9 @@
-astoycos:
-  name: Andrew Stoycos
-  description: Senior Software Engineer at Red Hat. network-policy-api co-lead.
-  avatar: https://github.com/astoycos.png
-Dyanngg:
-  name: Yang Ding
-  description: Senior Member of Technical Staff at VMware. network-policy-api co-lead.
-  avatar: https://github.com/dyanngg.png  
+authors:
+  astoycos:
+    name: Andrew Stoycos
+    description: Senior Software Engineer at Red Hat. network-policy-api co-lead.
+    avatar: https://github.com/astoycos.png
+  Dyanngg:
+    name: Yang Ding
+    description: Senior Member of Technical Staff at VMware. network-policy-api co-lead.
+    avatar: https://github.com/dyanngg.png  

site-src/npeps/npep-122.md

@@ -0,0 +1,191 @@
+# NPEP-122: Tenancy API
+
+* Issue: [#122](https://github.com/kubernetes-sigs/network-policy-api/issues/122)
+* Status: Provisional
+
+## TLDR
+
+Tenancy definition and the API (SameLabels/NotSameLabels) is confusing and ambiguous as of now. 
+We want to rethink the tenancy use cases and the API to keep it simple and easy to understand, but
+flexible enough to cover all defined use cases.
+
+## Goals
+
+- Clarify tenancy use cases.
+- Provide a complete definition of a tenant in respect to ANP.
+- Avoid unneeded tenancy configs that only exist because of ANP use cases.
+
+## Non-Goals
+
+- Define new use cases for tenancy (as opposed to clarify the ones we considered initially, but didn't explain well enough)
+- Define user stories for multiple tenancy policies in the same cluster.
+
+## Introduction
+
+The KEP doesn’t say a whole lot about tenants…
+
+From the Goals:
+
+    As a cluster administrator, I want to have the option to enforce in-cluster network level access controls that 
+    facilitate network multi-tenancy and strict network level isolation between multiple teams and tenants sharing 
+    a cluster via use of namespaces or groupings of namespaces per tenant.
+
+    Example: I would like to define two tenants in my cluster, one composed of the pods in foo-ns-1 and foo-ns-2 
+    and the other with pods in bar-ns-1, where inter-tenant traffic is denied.
+
+From the User Stories:
+
+    Story 4: Create and Isolate multiple tenants in a cluster
+
+    As a cluster admin, I want to build tenants in my cluster that are isolated from each other by default. 
+    Tenancy may be modeled as 1:1, where 1 tenant is mapped to a single Namespace, or 1:n, where a single tenant 
+    may own more than 1 Namespace.
+
+Elsewhere:
+
+    AdminNetworkPolicy Pass rules allows an admin to delegate security posture for certain traffic to the Namespace 
+    owners by overriding any lower precedence Allow or Deny rules. For example, intra-tenant traffic management can be 
+    delegated to tenant admins explicitly with the use of Pass rules.
+
+So really, the only solidly-agreed-upon use case is that you should be able to create enforced isolation 
+between particular sets of namespaces.
+
+### Clarifying user stories
+
+#### Story 4.1: Create and Isolate multiple tenants in a cluster by default, overridable isolation
+
+Here is the existing tenancy related user story from our website:
+
+    As a cluster admin, I want to build tenants in my cluster that are isolated from each other by default. 
+    Tenancy may be modeled as 1:1, where 1 tenant is mapped to a single Namespace, or 1:n, where a single tenant 
+    may own more than 1 Namespace.
+
+The wording used here has led to much confusion. Specifically, the "by default" part actually means this policy should 
+be at the BANP priority, and solves the "Engineering org vs Marketing org" use case where you want to keep orgs 
+from accidentally interfering with each other. By default, cross-tenant traffic should be dropped. 
+However, namespace owners can override this behavior by applying their own policies as needed. 
+
+In reality, the CR attached to this story defines strict tenancy, which should be a separate use case (see next section).
+
+To make the use case more obvious we can add some details to it like the following
+
+    As a cluster admin, I want to build tenants for different departments (e.g. Engineering vs Marketing) 
+    in my cluster that are isolated from each other by default.
+    By default, cross-tenant traffic is dropped. However, namespace owners can override this behavior by applying 
+    their own policies as needed.
+    Tenancy may be modeled as 1:1, where 1 tenant is mapped to a single Namespace, or 1:n, where a single tenant 
+    may own more than 1 Namespace.
+
+#### Story 4.2: Create and Isolate multiple tenants in a cluster, strict isolation
+
+Strict tenancy is the "Coke vs Pepsi" sort of thing where you want each tenant to feel like it has its own cluster, 
+and be totally independent of the other tenants. We can write it down like this
+
+    As a cluster admin, I want to build tenants for different organizations (e.g. Coke vs Pepsi) 
+    in my cluster that are isolated from each other, where this isolation
+    can't be overridden by namespace owners. This policy should make every tenant completely independent and isolated 
+    from other tenants. Tenancy may be modeled as 1:1, where 1 tenant is mapped to a single Namespace, or 1:n, where a single tenant 
+    may own more than 1 Namespace.
+
+#### Story 4.3: Allow internal connections for tenants
+
+    As a cluster admin, I want to build tenants in my cluster and always allow connections inside one tenant.
+    At the same time I want to setup an overridable deny-all policy to protect namespaces by default.
+    This policy should make sure internal connectivity for a tenant is always allowed, in case there are
+    lower-priority deny rules.
+
+#### Story 4.4: Tenants interaction with (B)ANP
+
+    As a cluster admin, I want to be able to setup policies with higher and lower priority than tenancy policy.
+    I want to deny inter-tenant connections, but I want to allow ingress traffic from the monitoring namespace
+    to all namespaces. Therefore, I need "allow from monitoring" rule to have higher priority than "deny from
+    other tenants".
+    I want to setup "deny all" BANP to protect cluster workloads, but I want to allow internal connections
+    within tenant. Therefore, I need "allow from same tenant" rule to have higher priority than "deny all" BANP.
+
+#### What I couldn't figure out user stories for
+
+- Skip action
+- Ports *[]AdminNetworkPolicyPort
+
+### Existing API
+
+AdminNetworkPolicy has the “SameLabels” and “NotSameLabels” fields to support the use cases involving tenancy. For example:
+
+**Use case**
+
+Traffic should be disallowed by default between namespaces owned by different users (defined by labels i.e `user=foo` or `user=bar`).
+
+**Policy**
+```
+kind: BaselineAdminNetworkPolicy
+apiVersion: policy.networking.k8s.io/v1alpha1
+metadata:
+  name: user-based-tenancy
+spec:
+  subject:
+    namespaces:
+      matchExpressions:
+        - key: user
+          operator: Exists
+  ingress:
+    - action: Deny
+      from:
+        - namespaces:
+            notSameLabels:
+              - user
+```
+
+**Meaning**
+
+In namespaces that have a “user” label, by default, deny ingress from namespaces that have a different “user” label.
+
+There are several major problems with this implementation of tenancy as it pertains to the user stories.
+
+First, There is no explicit definition of "tenancy" anywhere. The administrator has an idea of 
+"tenants are defined by the user label", but that's only true because this particular ANP happens to include that
+particular rule, and there's no way to find the ANP(s) that defines tenancy if you don't already know what they are.
+
+Second, the SameLabels/NotSameLabels selectors behave really differently from other peers, causing multiple underlying 
+rules to be created, and the syntax doesn't make that obvious.
+
+Third, the syntax is very general purpose / powerful. ANP has subjects and peers, which are different, 
+and currently Tenancy is defined on the peers side. Tenancy by itself has the same subject and peer, 
+at least for the existing use cases, and having separate selectors for subject and peer allows for more
+configurations than needed. 
+
+Fourth, the ANP subject allows using pod selectors, while tenancy use cases only need namespace selectors.
+
+## API
+
+TBD
+
+## Conformance Details
+
+TBD
+<!---
+(This section describes the names to be used for the feature or
+features in conformance tests and profiles.
+
+These should be `CamelCase` names that specify the feature as
+precisely as possible, and are particularly important for
+Extended features, since they may be surfaced to users.)
+-->
+
+## Alternatives
+
+Other alternatives were mentioned https://docs.google.com/document/d/113xBe7VMK7hMYdIdB9gobp7JwVkWQLnqdMPNkamfaK8/edit,
+but none of them cover all the Goals defined in this NPEP.
+
+There are 2 main problems with leaving Tenancy as a (B)ANP peer:
+1. tenancy is only based on namespace labels, but (B)ANP subject allows using pod selector too
+2. tenancy definition is less obvious, since it is a part of the peers list. Usually peer rules are the same for
+all (B)ANP subject pods, but for tenancy that is not true.
+3. There are actually more that 2 problems, mainly about allowing much more configurations for tenancy than we have
+user stories for, but it is covered in the previous sections :)
+
+Therefore, creating a new object seems like a more clear way to implement Tenancy.
+
+## References
+
+- https://docs.google.com/document/d/113xBe7VMK7hMYdIdB9gobp7JwVkWQLnqdMPNkamfaK8