Add runAsUser, runAsGroup, and allowPrivilegeEscalation to helm chart for Agones containers about agones HOT 8 CLOSED

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?

from agones.

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?

from agones.

@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.

from agones.

@jharris- Sure, sounds good!

from agones.

@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.

from agones.

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.

from agones.

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 😃

from agones.

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?

from agones.