Run as non-root, Kubernetes (Helm Chart) #208
Comments
|
@jballachino you'll need to have the customer look at using the Part of the issue is that the stock The Leader has the ability to run as non-root and correctly configures the Git settings. The Worker Group chart needs a few extra values to enable running as non-root. Here's a set of working values that makes Cribl run as the built-in LeaderWorker Group |
|
Thanks Brendan. I'll have the customer test and update back.
Jeff
…On Fri, Oct 18, 2024 at 1:33 PM Brendan Dalpe ***@***.***> wrote:
@jballachino <https://github.com/jballachino> you'll need to have the
customer look at using the securityContext values in the Helm charts.
Setting securityContext or podSecurityContext should enable the charts to
run as a non-root user.
Part of the issue is that the stock cribl/cribl container image is built
as the root user (uid 0), so attempting to write anything to /opt/cribl
inside the container fails when running as non-root.
The Leader has the ability to run as non-root and correctly configures the
Git settings. The Worker Group chart needs a few extra values to enable
running as non-root.
Here's a set of working values that makes Cribl run as the built-in nobody
user:
Leader
securityContext:
runAsUser: 65534
runAsGroup: 65534
runAsNonRoot: true
Worker Group
extraVolumeMounts:
- name: config-volume
mountPath: /opt/cribl/config-volume
env:
CRIBL_VOLUME_DIR: /opt/cribl/config-volume
podSecurityContext:
runAsUser: 65534
runAsGroup: 65534
runAsNonRoot: true
—
Reply to this email directly, view it on GitHub
<#208 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BMGORX67B7PCDL6XTP5JWBDZ4FA6HAVCNFSM6AAAAABQEC54FKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRSHEZTOMZTGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Hi Brendan -
I shared your recommendations with the customer. They provided the
following response:
*We have already tried the below recommendation, and the outcome was the
leader and worker processes were running but we were not able to configure
remote repository.*
*In our setup the git connectivity is via SSH-keys and when we run SSH
command in Leader pod shell it fails with error message “no user defined”.*
*We have also explained the same during our last connect with John Padilla,
and he acknowledged the issue is due to the Cribl base Image not configured
in a way to run as non-root user.*
*Please follow below cases that we worked on with support team.*
*00016512 – non-root user Issue*
*00016642 – Git Issue*
…On Fri, Oct 18, 2024 at 1:33 PM Brendan Dalpe ***@***.***> wrote:
@jballachino <https://github.com/jballachino> you'll need to have the
customer look at using the securityContext values in the Helm charts.
Setting securityContext or podSecurityContext should enable the charts to
run as a non-root user.
Part of the issue is that the stock cribl/cribl container image is built
as the root user (uid 0), so attempting to write anything to /opt/cribl
inside the container fails when running as non-root.
The Leader has the ability to run as non-root and correctly configures the
Git settings. The Worker Group chart needs a few extra values to enable
running as non-root.
Here's a set of working values that makes Cribl run as the built-in nobody
user:
Leader
securityContext:
runAsUser: 65534
runAsGroup: 65534
runAsNonRoot: true
Worker Group
extraVolumeMounts:
- name: config-volume
mountPath: /opt/cribl/config-volume
env:
CRIBL_VOLUME_DIR: /opt/cribl/config-volume
podSecurityContext:
runAsUser: 65534
runAsGroup: 65534
runAsNonRoot: true
—
Reply to this email directly, view it on GitHub
<#208 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BMGORX67B7PCDL6XTP5JWBDZ4FA6HAVCNFSM6AAAAABQEC54FKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRSHEZTOMZTGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@jballachino out of curiosity, what was the user id they configured for their security context? |
|
1001
…On Mon, Oct 21, 2024 at 1:08 PM Brendan Dalpe ***@***.***> wrote:
@jballachino <https://github.com/jballachino> out of curiosity, what was
the user id they configured for their security context?
—
Reply to this email directly, view it on GitHub
<#208 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BMGORX4E2G76NP47FQVPNMLZ4UYJBAVCNFSM6AAAAABQEC54FKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRXGI3TQNJZGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@jballachino I am able to reproduce this, but it's not something specific to Cribl. The user MUST exist inside the container in order to use Git/SSH. There's a very specific reason I chose 65534 with the In order to allow SSH as non-root/nobody, you need to add a With these Helm values, I was able to commit and push configs to a remote git repo. Alternatively, if the customer wants to use uid |
Note that the Securing Debian Manual states that
|
|
@benji-york The same concept can apply if you want to run Cribl as uid 1 ( |
|
Thanks Brendan. I passed along the additional details. I'll let you know
how it goes.
Jeff
…On Tue, Oct 22, 2024 at 9:17 AM Brendan Dalpe ***@***.***> wrote:
@jballachino <https://github.com/jballachino> I am able to reproduce
this, but it's not something specific to Cribl. The user MUST exist inside
the container in order to use Git/SSH.
There's a very specific reason I chose 65534 with the cribl/cribl
container image, as that user is nobody and already exists in the
/etc/passwd file.
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
In order to allow SSH as non-root/nobody, you need to add a
extraConfigmapMounts to the /nonexistent path, as that is the nobody's
home folder.
extraConfigmapMounts:
- name: nonexistent-user-gitconfig
mountPath: /nonexistent/.gitconfig
subPath: .gitconfig
configMap: logstream-leader-gitconfig
securityContext:
runAsUser: 65534
runAsGroup: 65534
runAsNonRoot: true
With these Helm values, I was able to commit and push configs to a remote
git repo.
Alternatively, if the customer wants to use uid 1001, the will need to
build a custom image and have it run the useradd so that it exists in
/etc/passwd and has a home directory where a .gitconfig file can be
mounted.
—
Reply to this email directly, view it on GitHub
<#208 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BMGORX462AKXFDSL6MYUIM3Z4ZF5ZAVCNFSM6AAAAABQEC54FKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRZGI3DENRRG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Hi Brendan,
Are you able to jump on a call with Cox Comms? They do not have configMap
setup similarly in their current environment and need some help
understanding the content of *configMap: logstream-leader-gitconfig*.
Please let me know. Thanks,
Jeff
On Thu, Oct 24, 2024 at 9:20 AM Jeff Ballachino ***@***.***>
wrote:
… Thanks Brendan. I passed along the additional details. I'll let you know
how it goes.
Jeff
On Tue, Oct 22, 2024 at 9:17 AM Brendan Dalpe ***@***.***>
wrote:
> @jballachino <https://github.com/jballachino> I am able to reproduce
> this, but it's not something specific to Cribl. The user MUST exist inside
> the container in order to use Git/SSH.
>
> There's a very specific reason I chose 65534 with the cribl/cribl
> container image, as that user is nobody and already exists in the
> /etc/passwd file.
>
> root:x:0:0:root:/root:/bin/bash
> daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
> bin:x:2:2:bin:/bin:/usr/sbin/nologin
> sys:x:3:3:sys:/dev:/usr/sbin/nologin
> sync:x:4:65534:sync:/bin:/bin/sync
> games:x:5:60:games:/usr/games:/usr/sbin/nologin
> man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
> lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
> mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
> news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
> uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
> proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
> www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
> backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
> list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
> irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
> gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
> nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
> _apt:x:100:65534::/nonexistent:/usr/sbin/nologin
>
> In order to allow SSH as non-root/nobody, you need to add a
> extraConfigmapMounts to the /nonexistent path, as that is the nobody's
> home folder.
>
> extraConfigmapMounts:
> - name: nonexistent-user-gitconfig
> mountPath: /nonexistent/.gitconfig
> subPath: .gitconfig
> configMap: logstream-leader-gitconfig
> securityContext:
> runAsUser: 65534
> runAsGroup: 65534
> runAsNonRoot: true
>
> With these Helm values, I was able to commit and push configs to a remote
> git repo.
>
> Alternatively, if the customer wants to use uid 1001, the will need to
> build a custom image and have it run the useradd so that it exists in
> /etc/passwd and has a home directory where a .gitconfig file can be
> mounted.
>
> —
> Reply to this email directly, view it on GitHub
> <#208 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/BMGORX462AKXFDSL6MYUIM3Z4ZF5ZAVCNFSM6AAAAABQEC54FKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRZGI3DENRRG4>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem Statement:
The current Cribl Helm chart installs a container that is owned by the root user. Security best practices advise against this and many customers have internal security policies that do not allow. We initially ran into permissions issues writing to /tmp/cribl/ volume. They were able to get around this specific issue by manually adding fsGroup: 1001 in the podSecurityContext section of the yaml config, but ran into other issues. Ultimately they were never able to successfully get the container to run as a non-root user.
Request:
We want to be able to have their containers created/owned by UID 1001 (or higher). Ideally they would like the ability to specify which UID/GID to assign within the Helm chart.
The text was updated successfully, but these errors were encountered: