Isolation using Namespaces

In Kubernetes, namespaces are a way to create virtual clusters within a physical cluster, providing resource isolation and segregation. Think of it like kernel namespace which is a feature to isolate resources from each other. Analogous to a physical world example, think of it like a store in a shopping mall which has its physical piece of land, electricity bill, water bill, and interior design in a shared shopping complex. The shopping complex is our cluster and the store is a namespace within the cluster. A namespace is a logical boundary that allows you to divide cluster resources and create separate environments for different applications, teams, or projects.

How Namespaces Create Isolation?

Resource isolation using namespaces helps prevent interference between different workloads running on the same Kubernetes cluster. Let’s see how it can be achieved:

Namespaced Scope

Kubernetes resources such as pods, services, deployments, and replica sets belong to a specific namespace. By default, resources are created in the default namespace if no namespace is specified. Each namespace provides an isolated environment where resources can be created and managed. This means that you could have a service called HelloWorld in a production namespace and a different service called HelloWorld in the test namespace and there won’t be any conflict.

Namespaces are logically isolated from one another but they can still communicate with services in another namespace.

Service DNS names follow the SERVICE.NAMESPACE.svc.cluster.local pattern. Kubernetes DNS service directory can easily locate any service by its name by using the expanded form of DNS addressing. To access the HelloWorld service in the production namespace, simply use helloworld.production

Resource Allocation

Namespaces allow you to allocate and limit resources separately for different workloads. For example, you can allocate a specific amount of CPU and memory resources to a namespace and the resources within the namespace will be constrained by the specified limits. This is done with the help of ResourceQuotas and LimitRanges which are the objects used to control resource usage by the cluster administrator.

ResourceQuota

The ResourceQuota is the total allocated resources for a particular namespace

apiVersion: v1
kind: ResourceQuota
metadata:
  name: quota
spec:
  hard:
    limits.cpu: "50"
    limits.memory: 100Gi
    requests.cpu: "25"
    requests.memory: 50Gi
    pods: "50"

LimitRange

LimitRange is used for managing constraints of resource allocation at a pod and container level within the namespace

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "resource-limits" 
spec:
  limits:
    -
      type: "Pod"
      max:
        cpu: "2" 
        memory: "1Gi" 
      min:
        cpu: "200m" 
        memory: "6Mi" 
    -
      type: "Container"
      max:
        cpu: "2" 
        memory: "1Gi" 
      min:
        cpu: "100m" 
        memory: "4Mi" 
      default:
        cpu: "300m" 
        memory: "200Mi" 
      defaultRequest:
        cpu: "200m" 
        memory: "100Mi" 
      maxLimitRequestRatio:
        cpu: "10"

Access Control

Namespaces provide a mechanism for access control and permissions. You can define role-based access control(RBAC) policies to grant different levels of access to users or groups for resources within a namespace. This enables fine-grained control over who can access and modify(update) resources within a specific cluster and also within a namespace, enhancing security and isolation. In RBAC there are three components

Users and Groups

Users are individuals who need access to the cluster, while groups are collections of users with similar roles

Roles

A role is a set of rules that define a set of permissions within a specific namespace. Roles can be created at the namespace level using Roleobject and are used to grant access to resources within the namespace. It is also possible to define the role which has access across the cluster using ClusterRole object

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  #
  # at the HTTP level, the name of the resource for accessing Secret
  # objects is "secrets"
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

RoleBindings and ClusterRoleBindings

RoleBindings associate a role with a user or a group, granting the defined permissions to the user/group within a specific namespace.

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
  name: jane # "name" is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role #this must be Role or ClusterRole
  name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBindings on the other hand, associate a role with a user/group across the entire cluster, granting permissions across all namespaces

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "dave" to read secrets in the "development" namespace.
# You need to already have a ClusterRole named "secret-reader".
kind: RoleBinding
metadata:
  name: read-secrets
  #
  # The namespace of the RoleBinding determines where the permissions are granted.
  # This only grants permissions within the "development" namespace.
  namespace: development
subjects:
- kind: User
  name: dave # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Implementing RBAC enforces strong access controls ensuring that only authorized users/groups have the appropriate level of access to cluster resources.

By leveraging namespaces, Kubernetes provides a powerful mechanism for isolating and managing resources within a cluster. It allows you to run multiple applications or projects on the same cluster without interference or noisy neighbor problem and provides control over resource allocation, access control, and resource quotas at the namespace level.