diff --git a/npeps/npep-133-fqdn-egress-selector.md b/npeps/npep-133-fqdn-egress-selector.md index 55a0a727..32ed2b37 100644 --- a/npeps/npep-133-fqdn-egress-selector.md +++ b/npeps/npep-133-fqdn-egress-selector.md @@ -16,14 +16,14 @@ Names](https://www.wikipedia.org/wiki/Fully_qualified_domain_name) (FQDNs). (for example `kubernetes.io`). * Support basic wildcard matching capabilities when specifying FQDNs (for example `*.cloud-provider.io`) -* Currently only `ALLOW` type rules are proposed. - * Safely enforcing `DENY` rules based on FQDN selectors is difficult as there +* Currently only `Accept` type rules are proposed. + * Safely enforcing `Deny` rules based on FQDN selectors is difficult as there is no guarantee a Network Policy plugin is aware of all IPs backing a FQDN policy. If a Network Policy plugin has incomplete information, it may accidentally allow traffic to an IP belonging to a denied domain. This would constitute a security breach. - By contrast, `ALLOW` rules, which may also have an incomplete list of IPs, + By contrast, `Accept` rules, which may also have an incomplete list of IPs, would not create a security breach. In case of incomplete information, valid traffic would be dropped as the plugin believes the destination IP does not belong to the domain. While this is definitely undesirable, it is at least @@ -179,8 +179,8 @@ spec: There are a couple ways to maintain an allowlist: -This example, includes the DENY rule in the same ANP object. It's also possible -to use another ANP object with a lower priority (e.g. `100` in this example): +This example, includes the Deny rule in the same CNP object. It's also possible +to use another CNP object with a lower priority (e.g. `100` in this example): ```yaml apiVersion: policy.networking.k8s.io/v1alpha1 kind: ClusterNetworkPolicy @@ -442,4 +442,4 @@ perform subsequent lookups to resolve CNAMEs returned for a particular query. In the above example, querying for `www.kubernetes.io.` returned a CNAME record for `kubernetes.io.`. When CNAME chasing is enabled, the DNS server will automatically resolve `kubernetes.io.` and return both records as the DNS -response. \ No newline at end of file +response. diff --git a/site-src/api-overview.md b/site-src/api-overview.md index 4ce2107f..de36d79f 100644 --- a/site-src/api-overview.md +++ b/site-src/api-overview.md @@ -8,7 +8,7 @@ personas, sometimes creating a complex web of objects to be maintained. In contrast, each resource in the Network Policy API is designed to be used by a specific persona. -With the advent of the ClusterNetworkPolicy resource Cluster Admins will now have +With the advent of the ClusterNetworkPolicy resource Cluster Admins will now have the ability to apply policy globally with only a few simple policy objects. ## Roles and personas @@ -60,13 +60,13 @@ Policy tiers are evaluated in the following order: ClusterNetworkPolicy can use 2 of these tiers: `Admin` and `Baseline`. -The `Admin` tier will help administrators set strict security rules for the cluster, -i.e. a developer CANNOT override these rules by creating NetworkPolicies that apply +The `Admin` tier will help administrators set strict security rules for the cluster, +i.e. a developer CANNOT override these rules by creating NetworkPolicies that apply to the same workloads as the ClusterNetworkPolicy. -The `Baseline` tier will allow administrators to set baseline security rules that -describe default connectivity for cluster workloads, which CAN be overridden by -developer NetworkPolicies if needed. +The `Baseline` tier will allow administrators to set baseline security rules that +describe default connectivity for cluster workloads, which CAN be overridden by +developer NetworkPolicies if needed. The major use case for `Baseline` tier is the ability to flip the [default security stance of the cluster](user-stories.md#story-5-cluster-wide-default-guardrails). @@ -101,32 +101,32 @@ CoreDNS for example). This traffic should not be blocked when developers apply NetworkPolicy to their Namespaces which isolates the workloads. ClusterNetworkPolicy `Pass` rules in the `Admin` tier allow an admin to delegate security posture for -certain traffic to the Namespace owners by overriding any lower precedence Allow +certain traffic to the Namespace owners by overriding any lower precedence Accept or Deny rules. For example, intra-namespace traffic management can be delegated to namespace admins explicitly with the use of `Pass` rules. More specifically traffic selected by a `Pass` rule will skip any lower precedence `Admin` tier rules and proceed to be evaluated by `NetworkPolicy` and -`Baseline` tier policies. When the `Pass` action is matched at the `Admin` tier, `NetworkPolicy` will +`Baseline` tier policies. When the `Pass` action is matched at the `Admin` tier, `NetworkPolicy` will apply next or if there is no `NetworkPolicy` match, `Baseline` policies will be evaluated. -### Priorities +### Priorities -Integer priority values were added to the ClusterNetworkPolicy API to allow Cluster -Admins to express direct and intentional ordering between various CNP Objects. -The `Priority` field in the CNP spec is defined as a non-negative integer value -where rules with lower priority values have higher precedence, and are checked +Integer priority values were added to the ClusterNetworkPolicy API to allow Cluster +Admins to express direct and intentional ordering between various CNP Objects. +The `Priority` field in the CNP spec is defined as a non-negative integer value +where rules with lower priority values have higher precedence, and are checked before policies with higher priority values in the same tier. -### Rules +### Rules -Each CNP should define at least one `Ingress` or `Egress` relevant in-cluster traffic flow -along with the associated Action that should occur. In each `gress` rule the user +Each CNP should define at least one `Ingress` or `Egress` relevant in-cluster traffic flow +along with the associated Action that should occur. In each `gress` rule the user should AT THE MINIMUM define an `Action`, and at least one `ClusterNetworkPolicyPeer`. Optionally the user may also define select `Protocols` to filter traffic on and also a name for each rule to make management and reporting easier for Admins. Within the `Protocols` array, `TCP`, `UDP`, or `SCTP` protocols can be specified, each with an -optional `DestinationPort`. The `DestinationPort` can be a single `Number` or a `Range` -with a `Start` and `End`. If `DestinationPort` is omitted, all ports for the specified +optional `destinationPort`. The `destinationPort` can be a single `number` or a `range` +with a `start` and `end`. If `destinationPort` is omitted, all ports for the specified protocol match. Alternatively, `DestinationNamedPort` can be used to target a port by name. A named port is @@ -135,10 +135,10 @@ a string to the name field alongside the containerPort. Existing named ports can inspecting the resource's YAML under `spec.containers[].ports` or by running `kubectl get pod -o jsonpath='{.spec.containers[*].ports[*].name}'`. Using a name instead of a number allows the ClusterNetworkPolicy to remain valid even if the container’s underlying port number is updated. -### Status +### Status -For `v1alpha2` of this API the ANP status field is simply defined as a list of +For `v1alpha2` of this API the CNP status field is simply defined as a list of [`metav1.condition`](https://github.com/kubernetes/apimachinery/blob/v0.25.0/pkg/apis/meta/v1/types.go#L1464)s. Currently there are no rules as to what these conditions should display, -and it is up to each implementation to report what they see fit. For further -API iterations the community may consider standardizing these conditions based on +and it is up to each implementation to report what they see fit. For further +API iterations the community may consider standardizing these conditions based on the usefulness they provide for various implementors. diff --git a/site-src/npeps/npep-133.md b/site-src/npeps/npep-133.md index f9d89b58..69d43a29 100644 --- a/site-src/npeps/npep-133.md +++ b/site-src/npeps/npep-133.md @@ -16,39 +16,39 @@ Names](https://www.wikipedia.org/wiki/Fully_qualified_domain_name) (FQDNs). (for example `kubernetes.io`). * Support basic wildcard matching capabilities when specifying FQDNs (for example `*.cloud-provider.io`) -* Currently only `ALLOW` type rules are proposed. +* Currently only `Accept` type rules are proposed. * Safely enforcing `DENY` rules based on FQDN selectors is difficult as there is no guarantee a Network Policy plugin is aware of all IPs backing a FQDN policy. If a Network Policy plugin has incomplete information, it may accidentally allow traffic to an IP belonging to a denied domain. This would constitute a security breach. - By contrast, `ALLOW` rules, which may also have an incomplete list of IPs, + By contrast, `Accept` rules, which may also have an incomplete list of IPs, would not create a security breach. In case of incomplete information, valid traffic would be dropped as the plugin believes the destination IP does not belong to the domain. While this is definitely undesirable, it is at least not an unsafe failure. -* Currently only AdminNetworkPolicy is the intended scope for this proposal. +* Currently only ClusterNetworkPolicy is the intended scope for this proposal. * Since Kubernetes NetworkPolicy does not have a FQDN selector, adding this - capability to BaselineAdminNetworkPolicy could result in writing baseline - rules that can't be replicated by an overriding NetworkPolicy. For example, - if BANP allows traffic to `example.io`, but the namespace admin installs a - Kubernetes Network Policy, the namespace admin has no way to replicate the - `example.io` selector using just Kubernetes Network Policies. + capability to Baseline tier of ClusterNetworkPolicy could result in writing + baseline rules that can't be replicated by an overriding NetworkPolicy. For + example, if CNP allows traffic to `example.io`, but the namespace admin + installs a Kubernetes Network Policy, the namespace admin has no way to + replicate the `example.io` selector using just Kubernetes Network Policies. ## Non-Goals * This enhancement does not include a FQDN selector for allowing ingress traffic. * This enhancement only describes enhancements to the existing L4 filtering as - provided by AdminNetworkPolicy. It does not propose any new L7 matching or + provided by ClusterNetworkPolicy. It does not propose any new L7 matching or filtering capabilities, like matching HTTP traffic or URL paths. * This selector should not control what DNS records are resolvable from a particular workload. * This enhancement does not provide a mechanism for selecting in-cluster endpoints using FQDNs. To select Pods, Nodes, or the API Server, - AdminNetworkPolicy has other more specific selectors. + ClusterNetworkPolicy has other more specific selectors. * Using the FQDN selector to refer to other Kubernetes endpoints, while not explicitly disallowed, is not defined by this spec and left up to individual providers. Trying to allow traffic to the following domains is NOT