Kubernetes has several nested layers, each of which provides some level of isolation and security. Building on the container, Kubernetes layers provide progressively stronger isolation. Here are the layers of a Kubernetes environment:
馃専饾悅饾惃饾惂饾惌饾悮饾悽饾惂饾悶饾惈 (饾惂饾惃饾惌 饾惉饾惄饾悶饾悳饾悽饾悷饾悽饾悳 饾惌饾惃 饾悐饾惍饾悰饾悶饾惈饾惂饾悶饾惌饾悶饾惉):
馃憠A container provides basic management of resources, but does not isolate identity or the network. It provides some security isolation, but only provides a single layer, compared to our desired double layer.
馃専饾悘饾惃饾悵:
馃憠A pod isolates a few more resources than a container, including the network. It does micro-segmentation using Kubernetes Network Policy, which dictates which pods can speak to one another. But it still suffers from noisy neighbors on the same host.
馃専饾悕饾惃饾悵饾悶:
馃憠A node includes a collection of pods, and has a superset of the privileges of those pods. A node leverages a hypervisor or hardware for isolation, including for its resources.
You can use firewall rules to restrict network traffic to the node.
馃専饾悅饾惀饾惍饾惉饾惌饾悶饾惈:
馃憠A cluster is a collection of nodes and a control plane. This is a management layer for your containers. Clusters offer stronger network isolation with per-cluster DNS.
馃専饾悘饾惈饾惃饾悾饾悶饾悳饾惌:
馃憠A GCP project is a collection of resources, including Kubernetes Engine clusters. A project provides all of the above, plus some additional controls that are GCP-specific, like project-level IAM for Kubernetes Engine and org policies. Resource names, and other resource metadata, are visible up to this layer.
There鈥檚 also the 饾悐饾惍饾悰饾悶饾惈饾惂饾悶饾惌饾悶饾惉 饾悕饾悮饾惁饾悶饾惉饾惄饾悮饾悳饾悶, the fundamental unit for authorization in Kubernetes. A namespace can contain multiple pods. Namespaces provide some control in terms of authorization, via namespace-level RBAC, but don鈥檛 try to control resource quota, network, or policies.
