Add runAsUser, runAsGroup, and allowPrivilegeEscalation to helm chart for Agones containers

[zmerlynn]

Is your feature request related to a problem? Please describe.

Allow securityContext fields such as runAsUser, runAsGroup, and allowPrivilegeEscalation to be set on agones-{allocator,extensions,controller,ping,sidecar}

https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

Describe the solution you'd like
Helm chart change

Describe alternatives you've considered
You can do this with kustomize.

[markmandel]

Not very familiar with these fields - but does it need to be configurable, or is this something we could set ourselves and leave on always?

On Agones we set the user and group, so that probably shouldn't be configurable? And I can't think of a situation where we'd want an Agones Pod to enable allowPrivilegeEscalation?

[ThatDevopsGuy]

@markmandel - I can't think of a reason why a game server would require a specific UID/GID. I could imagine that some binaries might want to bind to a privileged port to offer a some sort of file serving in-client (e.g. downloading a missing asset), however.

Perhaps it's best to let it be easily configurable with overrides, should they be needed, but the defaults comply with existing K8S security audits.

[jharris-]

Should be good to add runAsNonRoot to avoid needing to set the UID/GID.
In addition to the initial request, could you add the agones-gameserver-sidecar to the scope of work?

[zmerlynn]

@jharris- Sure, sounds good!

[markmandel]

@markmandel - I can't think of a reason why a game server would require a specific UID/GID.

This ticket isn't for GameServer pods though - you can set whatever you like on there via the GameServer.Spec.Template -- this is for the Agones components themselves.

I'm trying to work out why they should be configurable. It seems like they should be set to optimal values, whatever that may be.

[ThatDevopsGuy]

I'm trying to work out why they should be configurable. It seems like they should be set to optimal values, whatever that may be.

Another way to put it might be, is there any reason why runAsNonRoot wouldn't work? I think that might be all we need across the board, so the specific request might be better expressed as such.

[markmandel]

Another way to put it might be, is there any reason why runAsNonRoot wouldn't work? I think that might be all we need across the board, so the specific request might be better expressed as such.

I believe we are in furious agreement 😃

[zmerlynn]

That's good, because we were going to start with just defaulting this to runAsNonRoot, which will assert that the container images is doing the right thing.

But it's easy enough to make the securityContext blob configurable with that as the default. Are you saying it should not be?