Security primitives in Kubernetes

Security is prime in Kubernetes for hosting production. All-access to these hosts must be secured, root access disabled, password-based authentication disabled, and only ssh key-based authentication to be made available. And any other measures you need to take to secure the physical or virtual infrastructure that hosts Kubernetes.

Kube-apiserver is at the center of operations within Kubernetes. We interact with it through the kubectl utility or by accessing the API directly and through that you can perform almost any operation on the cluster.

This is the first line of defense. Controlling access to the API server itself.

  1. who can access the cluster?
    • who can access the API server is defined by the Authentication mechanisms.
    • there are different ways that you can authenticate to the API Server. Starting with user ids and passwords stored in a static file, to tokens, certificates, or integration with external authentication providers. Finally, for machines, we create service accounts.
  2. what can they do?
    • What can they do is defined by authorization mechanisms.
      • Role-Based Access Control, RBAC Authorization.
      • Attribute-Based Access Control, ABAC Authorization.
      • Node Authorization
      • Webhook Mode.

All Communication with the cluster, between the various components such as the ETCD cluster, Kube Controller Manager, Scheduler, API Server, and those running on the worker nodes such as kubelet and kubeproxy is secured using TLS Encryption.

By default all pods can access all other pods within the cluster. You can restrict access between them using Network Policies.

Leave a Reply

Your email address will not be published.

ANOTE.DEV