You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Unfortunately when you try and deploy this chart on a Kubernetes cluster where the default Pod Security Policy enforces MustRunAsNonRoot the nri-kube-events pod fails to start.
Interestingly the chart configures for the newrelic infra agent via a SecurityContext so that it runs as user 1000, but then goes on to set runAsNonRoot: false which then fall foul of the Pod Security Policy's MustRunAsNonRoot configuration.
Once this is changed to true the infra agent starts but the events container still fails as it has named user that Kubernetes can't work out if the user is root or not as it doesn't have a numeric id.
Really both these containers should probably work with a MustRunAsNonRoot configuration.
Describe the solution you'd like
The deployment of the nri-kube-events should be configured (if it can) to run as non-root for both containers. So fixing runAsNonRoot: false so it is runAsNonRoot: true for the infra agent and setting a security context for the events container would likely fix these issues.
Describe alternatives you've considered
None
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Unfortunately when you try and deploy this chart on a Kubernetes cluster where the default Pod Security Policy enforces MustRunAsNonRoot the nri-kube-events pod fails to start.
Interestingly the chart configures for the newrelic infra agent via a SecurityContext so that it runs as user 1000, but then goes on to set
runAsNonRoot: false
which then fall foul of the Pod Security Policy's MustRunAsNonRoot configuration.Once this is changed to true the infra agent starts but the events container still fails as it has named user that Kubernetes can't work out if the user is root or not as it doesn't have a numeric id.
Really both these containers should probably work with a MustRunAsNonRoot configuration.
Describe the solution you'd like
The deployment of the nri-kube-events should be configured (if it can) to run as non-root for both containers. So fixing
runAsNonRoot: false
so it isrunAsNonRoot: true
for the infra agent and setting a security context for the events container would likely fix these issues.Describe alternatives you've considered
None
The text was updated successfully, but these errors were encountered: