Networking & Security

Networking Model¶

Flat Network Topology¶

Kubernetes assumes a flat network model where all pods can communicate directly with each other and external services without NAT. Each pod is assigned a unique IP address, and the cluster network must ensure these IPs are routable across nodes. This design simplifies pod-to-pod communication but requires a reliable CNI (Container Network Interface) plugin to manage IP allocation and routing.

CNI Integration¶

The CNI is a standard interface that plugins use to configure network settings. Common CNI plugins include: - Calico (BGP-based overlay networking) - Flannel (VXLAN-based overlay) - Cilium (eBPF-based networking)

These plugins handle tasks like IP address assignment, routing, and firewall rules. For example, to verify CNI functionality, run:

kubectl get pods -o wide

This command displays pod IPs and their assigned network interfaces.

Service Abstraction¶

Kubernetes abstracts pod IPs using Services, which act as logical endpoints for pods. Services expose pods via DNS names (e.g., my-service.namespace.svc.cluster.local) and manage load balancing. To test DNS resolution:

nslookup my-service.namespace.svc.cluster.local

This resolves the service to its cluster IP, enabling seamless communication.

Security Foundations¶

Role-Based Access Control (RBAC)¶

RBAC defines fine-grained access policies to cluster resources. Key components include: - Roles (define permissions for specific resources) - RoleBindings (assign roles to users, service accounts, or groups) - ServiceAccounts (automatically created for pods to authenticate)

Example: Create a Role and bind it to a user:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Namespace Isolation¶

Namespaces provide logical isolation for resources (e.g., pods, services) but do not enforce strict security boundaries. They are useful for organizing workloads but should not replace RBAC or network policies. To list namespaces:

kubectl get namespaces

Network Policies¶

Network Policies control traffic between pods using iptables or eBPF (via Cilium). They define rules for ingress/egress traffic, such as allowing only specific ports or protocols. Example policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

This policy denies all traffic by default, enforcing strict isolation.

Key takeaways¶

Kubernetes uses a flat network model with CNI plugins to enable direct pod communication.
Services abstract pod IPs via DNS, simplifying service discovery and load balancing.
RBAC and network policies are critical for enforcing access control and traffic rules.
Namespaces provide organizational isolation but require RBAC for security.
Secrets are used to securely store sensitive data, but encryption at rest is handled by underlying storage systems.