In a Kubernetes cluster, every pod gets its own IP address. Pods can be treated much like VMs or physical hosts from the perspectives of port allocation, naming, service discovery, load balancing, application configuration, and migration.
Sharing the host network namespace breaks the isolation between container images and can make the host visible to other containers in the pod. In some cases, pods in the host network of a node can communicate with all pods on all nodes without using network address translation (NAT).
- Resource: PodSecurityPolicy
- Argument: hostNetwork (Optional)
When set to false, Pods are unable to use their host's network namespace.
apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: <policy name> spec: + hostNetwork: false
To use a PodSecurityPolicy resource, the requesting user or target pod’s service account must be authorized to use the policy. The preferred method is to grant access to the service account. In the following example we use RBAC, a standard Kubernetes authorization mode.
A Role or ClusterRole needs to grant access to use the desired policies.
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: <role name> rules: - apiGroups: ['policy'] resources: ['podsecuritypolicies'] verbs: ['use'] resourceNames: - <policy name>
The ClusterRole is then bound to the authorized service(s):
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: <binding name> roleRef: kind: ClusterRole name: <role name> apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount name: <authorized service account name> namespace: <authorized pod namespace>
Updated 12 months ago