search

cruise-automation / k-rail

Kubernetes security tool for policy enforcement
Apache License 2.0
444 stars 54 forks source link

exemptions on container level #132

Open empinator opened 2 years ago

empinator commented 2 years ago

Hi,

I am running k-rail on my kubernetes cluster combined with linkerd as service mesh to ensure mTLS communication between pods. linkerd will automatically inject further (init-)containers into my pod to accomplish this.

One of the injected containers require to be run with runAsNonRoot: false

...
    image: cr.l5d.io/linkerd/proxy-init:v1.4.0
    imagePullPolicy: IfNotPresent
    name: linkerd-init
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        add:
        - NET_ADMIN
        - NET_RAW
      privileged: false
      readOnlyRootFilesystem: true
      runAsNonRoot: false
      runAsUser: 0
...

then, of course k-rail is throwing a pod_no_root_user violation

I was wondering if there is a way to define an exemptions on container level within a pod?

Any help would be much appreciated.

funkypenguin commented 2 years ago

We have a similar issue with istio.. in order to use the istio-init initContainer, we'd have to exempt the pod_no_new_capabilities check for the replicaset/statefulset/daemonset controllers, which would effectively bypass the check altogether.

We've avoided the issue thus far by using Istio's CNI plugin (https://istio.io/latest/docs/setup/additional-setup/cni/), but this doesn't work with secure runtimes such as kata/gvisor.

mark-adams commented 1 year ago

👋 The k-rail project has been deprecated and is no longer under active development. We recommend taking a look at OPA Gatekeeper to see if it might meet your needs going forward.

Thanks for your contribution(s) to the project!