Is anyone able to override signoz yamls to make th...
# support
d
Is anyone able to override signoz yamls to make them more secure? basically if anyone has suggestions for pod security standards, pod security admissions and network policies?
@Srikanth Chekuri
also can we configure
infra-k8s-infra-otel-agent
to not use HostPath mount?
n
Hey @Dhruv garg, are you looking to apply policies at pod/deployment level?
d
yeah, pod security context, and container security context with network policies
was doing security scan, and found that signoz expose lot of vulnerabilities
n
We do support apply podSecurityContext , please take a look at the helm charts values: https://github.com/SigNoz/charts/blob/main/charts/signoz/README.md
if you dont mind what are the some of the vulnerabilities you've experienced
d
yeah I saw that values can be overridden, but I will have to go through all the containers used by signoz and check if something breaks after adding security context. so wanted to know if there is some list of permissions needed by each container and pod, based on which I can apply these policies? I was basically using
kubescape
tool to find vulnerabilitis in my cluster, and some of the vulnerabilities exposed by signoz are: • no network policies • use of
HostPath mount
by infra chart • no pod security context, and container security context • config files expose secrets/credentials ◦ not sure if this flagging was correct ◦ haven’t gone through all the charts of signoz • there were others also, but I will need to dig deeper to understand them
n
right!!, we don't have a explicit list of the permissions required for the containers, so you need to apply the context and check afterwards how it goes. Although we don't need elevated permissions for signoz containers, k8s-infra agent charts need elevated permission for getting the k8s context.
d
@Nagesh Bansal even manually adding security context is almost impossible, because volumes etc are not exposed in chart according to readme shared. Right now, I will have to run signoz container as root, because it keeps crashing otherwise, as it needs to create files for logs
cc @nitya-signoz