Linux Capabilities en environnement Docker/Kubernetes

Nous nous sommes intéressés récemment aux Linux Capabilities , dans le cadre de durcissement de containers Docker ou de cluster Kubernetes.

Il existe de nombreuses références à ce sujet sur Internet et dépasse l’objet de cet article.

Les Capabilities , intégrées aux Kernel Linux, permettent de décrire finement les droits nécessaires à un exécutable et sont référencées ici. Celles qui nous intéressent le plus souvent dans le cas du confinement de containers Docker sont  :

/* Allow interface configuration */
 /* Allow administration of IP firewall, masquerading and accounting */
 /* Allow setting debug option on sockets */
 /* Allow modification of routing tables */
 /* Allow setting arbitrary process / process group ownership on
 sockets */
 /* Allow binding to any address for transparent proxying (also via NET_RAW) */
 /* Allow setting TOS (type of service) */
 /* Allow setting promiscuous mode */
 /* Allow clearing driver statistics */
 /* Allow multicasting */
 /* Allow read/write of device-specific registers */
 /* Allow activation of ATM control sockets */

#define CAP_NET_ADMIN 12

/* Allow use of RAW sockets */
 /* Allow use of PACKET sockets */
 /* Allow binding to any address for transparent proxying (also via NET_ADMIN) */

#define CAP_NET_RAW 13

Un exemple de classique utilise le binaire « ping » :

root@srn:~# ls -lh /bin/ping
-rwsr-xr-x 1 root root 44K May  7  2014 /bin/ping

On constate que le bit S (setuid) est activé car ping nécessite le droit de créer une socket ICMP. Si « root » retire ce droit, le ping ne fonctionne plus pour l’utilisateur « toto »:

# chmod -s /bin/ping
# su toto
$ ping randco.fr
ping: icmp open socket: Operation not permitted

Si on ajoute la Capability NET_RAW, ping fonctionne à nouveau et ce nouveau droit est à la fois suffisant et bien plus restreint qu’un bit SETUID :

# setcap cap_net_raw+p /bin/ping
# su toto
$ ping randco.fr
PING randco.fr (164.132.216.245) 56(84) bytes of data.
64 bytes from 164.132.216.245: icmp_seq=1 ttl=57 time=5.72 ms
64 bytes from 164.132.216.245: icmp_seq=2 ttl=57 time=5.30 ms

Dans Kubernetes, les Pod Security Policies (PSP) permettent de détailler au niveau du Cluster les Capabilities à ajouter ou à retirer aux Pods. Ci-dessous un exemple de Policy très contrainte :

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  # Required to prevent escalations to root.
  allowPrivilegeEscalation: false
  # This is redundant with non-root + disallow privilege escalation,
  # but we can provide it for defense in depth.
  requiredDropCapabilities:
    - ALL
[..]

Pour apprendre par le test, nous ne pouvons que vous conseiller d’explorer https://contained.af/.

Si vous avez des questions plus globales sur la sécurisation de cluster Kubernetes, contactez-nous.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.