Ability to influence serviceaccount used in created deployment

[GijsvanDulmen]

I'm looking through the code but can't see a way to influence the serviceaccount used. The default serviceaccount would be unwise and probably in many setups has little to none rights. Would there be a way to specificy this as a label as well?

Thanks for kubedock!

Regards,
Gijs van Dulmen

[joyrex2001]

The service account is managed by the component that deploys the container. For example, if tekton would be used to run pipelines that have kubedock running as a sidecar, you would use the serviceAccount field in the PipelineRun resource (see here). You could then create a specific service account (using the rbac example from the readme), or extend the default tekton service account with the required rbac.

[GijsvanDulmen]

Hmm.. I'm not quite sure I understand. I'm running the Task with the "kubedock" serviceaccount which has all the RBAC in place to create a deployment etc (like the RBAC listed in the README). But the deployment created still creates Pods with the default serviceaccount. So for example a PostgreSQL instance which has been spinned up is running with the default serviceAccount.

[joyrex2001]

Check, I misunderstood. You want to influence the serviceAccount in the containers that are spun up by kubedock. That makes sense. I think something like providing a command-line argument for that would be sufficient right?

[GijsvanDulmen]

That would help. Maybe even a label which maps to the used serviceAccount?

[joyrex2001]

Added both label com.joyrex2001.kubedock.service-account and argument --service-account.

[GijsvanDulmen]

Wow! That was quick. Thanks a lot!

[joyrex2001]

I removed the override via the label; this can allow privilege escalation via a test if there are service accounts in the namespace kubedock is running that have more privileges.