Is it possible to use the CRD `NvSecurityRule` to ...
# neuvector-security
a
Is it possible to use the CRD
NvSecurityRule
to allow-list extra processes on the neuvector controller pods themselves?
q
With the caveat that I don’t actually know for certain, I’m gonna go so far as to suggest that I highly doubt it. What madness are you up to? 🤣
a
🫣
We're hitting issues caused by this switch in 5.4.3 to harden some of the base allowlisting. The images we're using aren't the upstream ones, and I think that the
cat /tmp/ready
probes have a different path for cat (still trying to figure out the exact "why") so I was trying to test allowing cat with that path for the controllers.
Need to redeploy but I can grab the exact deny log we're seeing. It might be easy enough to fix in the image we're using, but from the log I wasn't sure why it was getting denied.
👍 1
Copy code
2025-04-25T20:45:14.319|DEBU|AGT|probe.(*Probe).IsAllowedShieldProcess: SHD: - id=c95d66a01fea6c59d66d10bcae084aacbde4025d0b35c3741085dfe05831aa07 pid=61161 ppe=&{Name:cat Path:/usr/bin/coreutils User:root Uid:0 Hash:[] Action:deny CfgType:0 CreatedAt:0001-01-01 00:00:00 +0000 UTC UpdatedAt:0001-01-01 00:00:00 +0000 UTC Uuid:00000000-0000-0000-0000-000000000000 DerivedGroup: AllowFileUpdate:false ProbeCmds:[]} proc=&{pname:runc ppath:/x86_64-bottlerocket-linux-gnu/sys-root/usr/bin/runc name:cat path:/usr/bin/coreutils cmds:[/usr/bin/coreutils --coreutils-prog-shebang=cat /usr/bin/cat /tmp/ready ] user:root pid:61161 ppid:61152 sid:1966 pgid:59414 ruid:0 euid:0 retry:0 inspectTimes:0 startTime:{wall:13977795514742820424 ext:62744828455 loc:0x4ed7240} lastScanTime:{wall:13977795514742820424 ext:62744828455 loc:0x4ed7240} scanTimes:0 reported:64 action:allow riskyChild:false riskType: execScanDone:false}
Guess cat comes from coreutils on this image (ubi base image) 🫠
Copy code
switch path {
 			case "/usr/bin/cat": // k8s readiness probe
This is the new process allow logic I think? Which wouldn't support cat being provided by a multicall binary like busybox/coreutils.
It's obviously not an issue with the dockerhub images so I can see this just being an unsupported thing but it seems like it could be a pain to fix this if we don't have a hook into allowing other processes on the controller.
q
Can you specify the “/usr/bin/cat” in HELM? ( i have not tried this)
a
I made this PR yesterday to expose the probes in helm values - https://github.com/neuvector/neuvector-helm/pull/487 - although I need to figure out what would actually work as an allowed probe instead of
cat /tmp/ready
. It seems like if I use the
cat
process from the image at all, NeuVector is (correctly) going to detect that the path is coreutils path and block it? From what I can tell that "allowed cat path" is hardcoded here (along with some other allowed paths). Haven't yet found a hook into there to allow other processes.
q
I think if you're not getting the "official" builds, that are on BCI, it becomes kinda wild west. ¯\_(ツ)_/¯
a
Yeah I think that's fair 😢. Feels like more generically there might be value in allowing end users to specify extra processes to allow on the neuvector system containers? I can see the side of "well why would you" but it seems wise to provide a hook into that for worst case debugging, etc? 🤷
q
i nudges engineering about your PRs. 😉
❤️ 1