Support for dynamically adding namespace as a game deployment namespace

[aimuz]

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

https://agones.dev/site/docs/installation/install-agones/helm/#namespaces

When I needed to add namespaces, I realized that I had to create the namespace first and then use helm to add the namespaces to it in order for it to work properly, otherwise I would get this error

  Normal   PortAllocation  55s   gameserver-controller  Port allocated
  Warning  Error           55s   gameserver-controller  pods "simple-game-server-g6bjc" is forbidden: error looking up service account demo/agones-sdk: serviceaccount "agones-sdk" not found

This is giving me a hard time because I have to log the last helm parameter or it will be potentially lost in the next update.

Describe the solution you'd like

I would expect that he should always be available when using Game Server, or do a small amount of pre-work, such as adding a specified tag to namespace to enable the feature.

Describe alternatives you've considered

• Create an agones operator, use the operator to create agones and update agones, then the changes to the parameters will also be present in the document.
• No changes are made to the installation method, creating serviceaccount for all game-server
• Listens to all namespaces, and creates a shared serviceaccount in the namespace when a game-server object appears in the namespace.
• For a namespace with a specified label added, serviceaccount is added by default, even if it does not have a gs object

These are some of the options I have listed

Additional context Add any other context or screenshots about the feature request here.

[markmandel]

If the helm template created the namespace in the list provided to gameservers.namespaces, if it didn't already exist (I'd have to check if that is possible though) - would that solve the issue?

[aimuz]

If the gameservers.namespaces value is set to a namespace that does not exist, then it will fail, indicating that the namespace does not exist, and the serviceaccount will not be created after the namespace is created.

Another idea I have is to remove the dependency of the sdk-server on serviceaccount. The sdk-server will use the controller if it changes state, and they can probably use another protocol between them, such as grpc.

[aimuz]

Of course, for now, the easiest way is to have the controller create the serviceaccount when it creates the pod

[aimuz]

Do you guys have any new ideas? I think the easiest stage for now is to create serviceaccount automatically.

This will be done if you agree.

[markmandel]

Of course, for now, the easiest way is to have the controller create the serviceaccount when it creates the pod

Sorry, this won't be accepted. To do this, Agones' controller service account would need permission to manipulate RBAC permissions. That's a huge permission to have from a security perspective.

This has come up a few times over the years, and every time the RBAC permission issue is a blocker.

[aimuz]

Yes, indeed, there is another way to remove the dependency on serviceaccount, and for now all gs pods have ClusterRole access

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: {{ .Values.agones.serviceaccount.sdk.name }}
  namespace: {{ .Release.Namespace }}
  labels:
    app: {{ template "agones.name" . }}
    chart: {{ template "agones.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
rules:
- apiGroups: [""]
  resources: ["events"]
  verbs: ["create", "patch"]
- apiGroups: ["agones.dev"]
  resources: ["gameservers"]
  verbs: ["list", "update", "watch"]
---

And if you are using a non-helm installation, you can't actually add namespaces

[markmandel]

Right - but then every sidecar can access every namespace - we lose isolation on a container that is attached to a public interface.

Having it the way it is now limits some of the potential blast radius if a game server gets compromised, since it can't step outside of it's assigned namespace. If we expand the RBAC rules, it gives that Pod a wider permission set -- really only to solve some relatively slight developer friction.

I think I've mention it before, but if someone wanted to write a third-party controller that automatically created service accounts in namespaces that are created (maybe with a label?) for use at development time, I think that would be great -- but I wouldn't advocate for it at production time.

[wowq]

So, if I understand correctly, you're saying that we can automatically create a service account and role binding when creating a namespace, right?

[markmandel]

So, if I understand correctly, you're saying that we can automatically create a service account and role binding when creating a namespace, right?

Yep - nothing stopping you from doing this via yaml, a controller or something else -- or update the helm install with the new namespace list, and it will do it for you.

[github-actions[bot]]

'This issue is marked as Stale due to inactivity for more than 30 days. To avoid being marked as 'stale' please add 'awaiting-maintainer' label or add a comment. Thank you for your contributions '

[github-actions[bot]]

This issue is marked as obsolete due to inactivity for last 60 days. To avoid issue getting closed in next 30 days, please add a comment or add 'awaiting-maintainer' label. Thank you for your contributions