Access to a privileged container allows for breakout to the underlying host

[lance5890]

1. I have seen many ocp containers have set the ""privileged": true"

       "terminationMessagePolicy": "FallbackToLogsOnError",
       "imagePullPolicy": "IfNotPresent",
       "securityContext": {
         "privileged": true
       }

2. I just wonder why should the etcd containerd should set the "privileged": true flag. compared to the kubeadm installation, the etcd container has not this flag

3. when using standard container runtimes (for example ContainerD or CRI-O) access to a privileged container allows for easy breakout to the underlying host, which in turn allows for access to all other workloads on that host and credentials for the node agent (Kubelet)

[lance5890]

@Elbehery @tjungblu

[tjungblu]

I just wonder why should the etcd containerd should set the "privileged": true flag.

because we write the etcd data dir onto a hostPath, which requires this unfortunately.

[lance5890]

I just wonder why should the etcd containerd should set the "privileged": true flag.

because we write the etcd data dir onto a hostPath, which requires this unfortunately.

1 but even without the 'privileged: true', the etcd can also write to /var/lib/etcd 2 as the etcd container run as root by default

[tjungblu]

I doubt that you can just mount /var/lib/etcd on the host without it. But feel free to try, you already know how to run PRs. Plenty of detail around this in https://kubernetes.io/docs/concepts/storage/volumes/#hostpath

[lance5890]

I doubt that you can just mount /var/lib/etcd on the host without it. But feel free to try, you already know how to run PRs. Plenty of detail around this in https://kubernetes.io/docs/concepts/storage/volumes/#hostpath

can I join the cluster-etcd-operator as a member ? that would be my honor

[tjungblu]

Unless you're at RedHat and can authenticate via our SSO the automation won't be able to add you :) But I'm happy to give you the ok-to-test label to try it out.