Ensure that a unique Certificate Authority is used for etcd

Use a different certificate authority for etcd from the one used for Kubernetes, etcd is a highly available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. Its access should be restricted to specifically designated clients and peers only

Risk Level: High
Cloud Entity: Pods
CloudGuard Rule ID: D9.K8S.IAM.86
Covered by Spectral: No
Category: Compute

GSL LOGIC

KubernetesPod where labels contain [value='etcd'] and namespace = 'kube-system' should have spec.containers with  [parsedArgs contain [key like 'trusted-ca-file' and getValue('value')]] and getResources('KubernetesPod') contain-none[labels contain [value='api-server'] and namespace = 'kube-system' and spec.containers with [parsedArgs contain [key like 'client-ca-file' and value = ~getValue('value')]]]

REMEDIATION

Follow the etcd documentation and create a dedicated certificate authority setup for the
etcd service.
Then, edit the etcd pod specification file /etc/kubernetes/manifests/etcd.yaml on the
master node and set the below parameter.
--trusted-ca-file=</path/to/ca-file>

References:

  1. https://coreos.com/etcd/docs/latest/op-guide/security.html

Pods

Pods are the smallest deployable units of computing that can be created and managed in Kubernetes.A Pod is a group of one or more containers (such as Docker containers), with shared storage/network, and a specification for how to run the containers.

Compliance Frameworks

  • CIS Kubernetes Benchmark v1.20
  • CIS Kubernetes Benchmark v1.23
  • CIS Kubernetes Benchmark v1.24
  • CIS Kubernetes Benchmark v1.4.0
  • CIS Kubernetes Benchmark v1.5.1
  • CIS Kubernetes Benchmark v1.6.1