Allow the Infinispan pod's ServiceAccount to be configured in the Infinispan CR

[srilakshmi-b-a]

Hi Team ,

Need a placeholder in ISPN pod config to specify the service account name to be used while deploying.

https://infinispan.zulipchat.com/#narrow/channel/118645-infinispan/topic/where.20to.20specify.20service.20account.20name.20in.20the.20infinispan.20spec/with/563973410

[ryanemerson]

We could configure this as part of the container config as so:

spec:
  service:
    container:
      serviceAccountName: example-account

As well as the cluster pods, the various zero-downtime pods, the ConfigListener and the GossipRouter should also respect the configured value.

We could allow separate service account configuration for the ConfigListener and GossipRouter, but I think we should start with the single configuration until a user informs us of a need for this.

@Crumby It's a separate issue, but the existence of spec.service.container and spec.container is confusing. Maybe we should deprecate one in favour of the other? The simplest option would be deprecating spec.container as it has less configuration options.

[Crumby]

I wonder if the spec.*.container is the right place. serviceAccountName on it's own lies right under Pods spec. So maybe something like:

spec:
  serviceAccount:
   serviceAccountName: xyz
   serviceAccountNameRouter:
   ...

or

spec:
  serviceAccount:
  serviceAccountName: xyz
 configListener:
   serviceAccountName
   ...

@Crumby It's a separate issue, but the existence of spec.service.container and spec.container is confusing. Maybe we should deprecate one in favour of the other? The simplest option would be deprecating spec.container as it has less configuration options.

I've created #2426 for further discussions.

[ryanemerson]

serviceAccountName on it's own lies right under Pods spec

Good point, so maybe we just have it as a simple field instead of nesting?

I like the idea of having the configListener config nested within it's own domain, so how about:

spec:
  serviceAccountName: example1
  configListener:
    ServiceAccountName: example2
  service:
    sites:
      local:
        discovery:
          ServiceAccountName: example3

It's not ideal that the GossipRouter config is so nested and still under spec.service.*, but it does keep the relevant GossipRouter config grouped.

Any thoughts @pruivo @srilakshmi-b-a ?

[srilakshmi-b-a]

@ryanemerson Defining serviceAccountName only at the spec level may be sufficient initially, but providing separate service account configuration for the pod, config listener, and discovery improves debuggability and allows finer-grained RBAC control over time.

[pruivo]

@ryanemerson, remind me why the gossip router needs a service account?

[ryanemerson]

@pruivo Apologies the important part of the context was on Zulip:

We have infinispan images stored in Harbor registry , ISPN pods are using k8 default service account to pull the secrets , using the secret ISPN images are pulled from Harbor. Here the problem is , we do not want the ISPN pod to use default service account because it's not team specific , it's organization level. We want ISPN pod to use a specific ServiceAccount which has our secrets to pull our images from Harbor . PFA which has serviceaccountname "default" for better understanding our requirement

So the GossipRouter should also be using a defined ServiceAccount so that the default SA is not used.

[pruivo]

No worries, I should have searched for it.

One last question, using your suggestion, is there a niche use case where the Gossip Router pod requires a different service account from the Infinispan Server pod? Both use the same image and, given the pull secrets requirement, they can use the same service account.

spec:
  serviceAccountName: example1
  configListener:
    serviceAccountName: example2
  service:
    sites:
      local:
        discovery:
          serviceAccountName: example3

[ryanemerson]

is there a niche use case where the Gossip Router pod requires a different service account from the Infinispan Server pod?

I don't know of one.

Maybe the following is sufficient as the ConfigListener uses the Operator image, not the Infinispan server image:

spec:
  serviceAccountName: example1 # GossipRouter and Infinispan pods
  configListener:
    serviceAccountName: example2

[pruivo]

It sounds good to me.

Somewhat related, isn't the config listener pod running in the same namespace as the operator pod? Or does each Infinispan cluster has it own config listener?

[ryanemerson]

Each Infinispan cluster has it's own ConfigListener deployed in the same namespace as the cluster.

[srilakshmi-b-a]

@ryanemerson May I know when will this be done . It's a request from our side to get this done soon . We have some rollout in office which is affecting us if we don't make this service account change in our CR

[Crumby]

@srilakshmi-b-a We're currently working on higher priority tasks. So the implementation likely won't be done earlier than March