-
I'm attempting to run kubernetes/node-problem-detector on EKS as a DaemonSet. However, the specified kind: DaemonSet
metadata:
name: node-problem-detector
namespace: kube-system
spec:
template:
spec:
hostPID: true
hostIPC: true
hostNetwork: true
containers:
- name: node-problem-detector
securityContext:
privileged: true
seLinuxOptions:
user: system_u
role: system_r
type: super_t
level: s0 When I drop into ps -efZ | grep /node-problem-detector
Notably here is the labeling of
This is causing issues when the container goes to access a resource labeled as follows: journalctl -xef | grep selinux
Said resource: ls -lZ /x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/systemd/system/containerd.service
Version info: Details
sestatus
apiclient get {
"os": {
"arch": "x86_64",
"build_id": "9cd59298",
"pretty_name": "Bottlerocket OS 1.14.0 (aws-k8s-1.24)",
"variant_id": "aws-k8s-1.24",
"version_id": "1.14.0"
}, Is there anything in particular I am overlooking? Thank you community for any guidance and insight you can afford! 🙇 |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
It's almost possible to roll your own The main privilege that can't be picked up that way is the ability to modify all devices, since there's no field for that in the security context. |
Beta Was this translation helpful? Give feedback.
privileged: true
causes the "what label should I use?" logic in containerd-cri to take a different path, which leads to no specific label being set and getting the default domain transition tocontrol_t
.It's almost possible to roll your own
privileged: true
equivalent (by adding all capabilities, setting a privileged SELinux label, disabling seccomp).The main privilege that can't be picked up that way is the ability to modify all devices, since there's no field for that in the security context.