Allow setting automountServiceAccountToken on replication controller

[calind]

Currently the the kubernetes_replication_controller creates the spec with automountServiceAccountToken set to false. This means that the service account credentials selected by service_account_name are not available in the container.

https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server

[sl1pm4t]

@calind @radeksimko I have a fix for this in my fork, and will send over a PR.

[radeksimko]

Hi @calind
see more detailed explanation of why we don't support this field and why it's hardcoded to false at #38 (comment)

The service account does expose default_secret_name in case you want to replicate the behaviour.

@sl1pm4t I'm fairly confident you can't make RC/Pod/ServiceAccount creation idempotent with automountServiceAccountToken - try creating the resource and then running plan after a few seconds when the token was attached.

Let me know if the explanation makes sense and whether we can close this.

[sl1pm4t]

Hi @radeksimko - I disagree that we can't make the creation idempotent. As discussed in PR #57 if we ignore volumes / volumeMounts with a name matching default-token-* on read then there won't be a diff. I'm sure something similar could be done for a ServiceAccount.
Sure it's not perfectly elegant, and has a small gotcha, but I think it's a better option than not allowing automountServiceAccountToken, and breaking expected + documented behaviour of Kubernetes.

[radeksimko]

Hi @sl1pm4t
it's unfortunately not that simple due to the way Token Controller works.

Basically the fix you're proposing only deals with situation where there's no service_account specified, so the default one is used, hence default-token- naming scheme is used.
The secret name (which is then used for the volume/mount name) is generated from service account name, see https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/serviceaccount/tokens_controller.go#L384

So we'd have to ignore all of *-token-* which would be IMO a bit too aggressive.

I have opened kubernetes/kubernetes#51328 to track the upstream feature request as discussed earlier.

Are you happy for me to close this issue & related PR #57 and move the discussion over to kubernetes/kubernetes#51328 ?

Just to clarify - I really want to give users the chance to specify this field and use this handy functionality, but I'd like to do so with minimal (ideally no) disruption for anyone, that's why I believe upstream changes should take place first.

Let me know if that makes sense.

[sl1pm4t]

Ok I see your point @radeksimko - thanks for taking the time to explain.

[ccope]

@radeksimko do you have a clear path forward after the discussion on kubernetes/kubernetes#51328 ? I just spent the better part of an hour figuring out why the service account secret wasn't getting populated in my container :-)

[radeksimko]

@ccope The plan is to add validation to prevent people from using kubernetes_secret to manage service tokens and then add filtering based on type of the secret.

[victorsmirnov]

How should I put 'secrets' to my POD the right way?

I suggest to put an example to the documentation with simple explanation how this should be done. May be I'm missing something but after reading all these discussions I still do not understand how I should do this.

[moritzheiber]

A short term remedy for this issue would be to have a data source read the secret name of the service account, which you could then use to mount the token into your pod. It's cumbersome and I'd prefer a better solution, but for now this is what we're doing using a combination of kubectl and terraform with a variable ☹️

[schuettecarsten]

When will this be released?

[moritzheiber]

According to the Changelog this was released in July 😃

[aareet]

This should be resolved -> #56 (comment). Please reopen if that's not the case.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!