Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update NetworkPolicy docs for v1 #4003

Merged
merged 1 commit into from
Jun 7, 2017
Merged

Update NetworkPolicy docs for v1 #4003

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
74 changes: 38 additions & 36 deletions docs/concepts/services-networking/networkpolicies.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,7 @@
assignees:
- thockin
- caseydavenport
- danwinship
title: Network Policies
redirect_from:
- "/docs/user-guide/networkpolicies/"
Expand All @@ -13,53 +14,26 @@ redirect_from:

A network policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints.

`NetworkPolicy` resources use labels to select pods and define whitelist rules which allow traffic to the selected pods in addition to what is allowed by the isolation policy for a given namespace.
`NetworkPolicy` resources use labels to select pods and define rules which specify what traffic is allowed to the selected pods.

## Prerequisites

You must enable the `extensions/v1beta1/networkpolicies` runtime config in your apiserver to enable this resource.
Network policies are implemented by the network plugin, so you must be using a networking solution which supports `NetworkPolicy` - simply creating the resource without a controller to implement it will have no effect.

You must also be using a networking solution which supports `NetworkPolicy` - simply creating the
resource without a controller to implement it will have no effect.
## Isolated and Non-isolated Pods

By default, pods are non-isolated; they accept traffic from any source.

## Configuring Namespace Isolation

By default, all traffic is allowed between all pods (and `NetworkPolicy` resources have no effect).

Isolation can be configured on a per-namespace basis. Currently, only isolation on inbound traffic (ingress) can be defined. When a namespace has been configured to isolate inbound traffic, all traffic to pods in that namespace (even from other pods in the same namespace) will be blocked. `NetworkPolicy` objects can then be added to the isolated namespace to specify what traffic should be allowed.

Ingress isolation can be enabled using an annotation on the Namespace.

```yaml
kind: Namespace
apiVersion: v1
metadata:
annotations:
net.beta.kubernetes.io/network-policy: |
{
"ingress": {
"isolation": "DefaultDeny"
}
}
```

To configure the annotation via `kubectl`:

```shell
{% raw %}
kubectl annotate ns <namespace> "net.beta.kubernetes.io/network-policy={\"ingress\": {\"isolation\": \"DefaultDeny\"}}"
{% endraw %}
```
Pods become isolated by having a NetworkPolicy that selects them. Once there is any NetworkPolicy in a Namespace selecting a particular pod, that pod will reject any connections that are not allowed by any NetworkPolicy. (Other pods in the Namespace that are not selected by any NetworkPolicy will continue to accept all traffic.)

## The `NetworkPolicy` Resource

See the [api-reference](/docs/api-reference/extensions/v1beta1/definitions/#_v1beta1_networkpolicy) for a full definition of the resource.
See the [api-reference](/docs/api-reference/networking/v1/definitions/#_v1_networkpolicy) for a full definition of the resource.

An example `NetworkPolicy` might look like this:

```yaml
apiVersion: extensions/v1beta1
apiVersion: networking/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
Expand Down Expand Up @@ -93,8 +67,36 @@ __ingress__: Each `NetworkPolicy` includes a list of whitelist `ingress` rules.

So, the example NetworkPolicy:

1. allows connections to tcp port 6379 of "role=db" pods in the "default" namespace from any pod in the "default" namespace with the label "role=frontend"
2. allows connections to tcp port 6379 of "role=db" pods in the "default" namespace from any pod in a namespace with the label "project=myproject"
1. isolates "role=db" pods in the "default" namespace (if they weren't already isolated)
2. allows connections to tcp port 6379 of "role=db" pods in the "default" namespace from any pod in the "default" namespace with the label "role=frontend"
3. allows connections to tcp port 6379 of "role=db" pods in the "default" namespace from any pod in a namespace with the label "project=myproject"

See the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) for further examples.

## Default policies

You can create a "default" isolation policy for a Namespace by creating a NetworkPolicy that selects all pods but does not allow any traffic:

```yaml
apiVersion: networking/v1
kind: NetworkPolicy
metadata:
name: default-deny
spec:
podSelector:
```

This ensures that even pods that aren't selected by any other NetworkPolicy will still be isolated.

Alternatively, if you want to allow all traffic for all pods in a Namespace (even if policies are added that cause some pods to be treated as "isolated"), you can create a policy that explicitly allows all traffic:

```yaml
apiVersion: networking/v1
kind: NetworkPolicy
metadata:
name: allow-all
spec:
podSelector:
ingress:
- {}
```
31 changes: 4 additions & 27 deletions docs/tasks/administer-cluster/declare-network-policy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
---
assignees:
- caseydavenport
- danwinship
title: Declaring Network Policy
redirect_from:
- "/docs/getting-started-guides/network-policy/walkthrough/"
Expand Down Expand Up @@ -68,35 +69,11 @@ Connecting to nginx (10.100.0.16:80)

## Limit access to the `nginx` service

Let's say you want to limit access to the `nginx` service so that only pods with the label `access: true` can query it. The first step is to enable ingress isolation on the `default` namespace. This prevents **_any_** pods from accessing the `nginx` service.

```console
$ kubectl annotate ns default "net.beta.kubernetes.io/network-policy={\"ingress\": {\"isolation\": \"DefaultDeny\"}}"
```

## Test the access limitation

Test to see that with ingress isolation in place, you no longer have access to the `nginx` service:

```console
$ kubectl run busybox --rm -ti --image=busybox /bin/sh
Waiting for pod default/busybox-472357175-y0m47 to be running, status is Pending, pod ready: false

Hit enter for command prompt

/ # wget --spider --timeout=1 nginx
Connecting to nginx (10.100.0.16:80)
wget: download timed out
/ #
```

## Create a policy that allows connections from authorized pods

Next, create a `NetworkPolicy` that allows connections from pods with the label `access: true`.
Let's say you want to limit access to the `nginx` service so that only pods with the label `access: true` can query it. To do that, create a `NetworkPolicy` that allows connections only from those pods:

```yaml
kind: NetworkPolicy
apiVersion: extensions/v1beta1
apiVersion: networking/v1
metadata:
name: access-nginx
spec:
Expand All @@ -119,7 +96,7 @@ networkpolicy "access-nginx" created
```

## Test access to the service when access label is not defined
If we attempt to access the nginx Service from a pod without the correct labels, the request will still time out:
If we attempt to access the nginx Service from a pod without the correct labels, the request will now time out:

```console
$ kubectl run busybox --rm -ti --image=busybox /bin/sh
Expand Down