Do not hardcode AutomountServiceAccountToken #38
Comments
|
Hi @mingfang In fact I wish there was a similar way to disable creation of default secrets in the service account. I had to work around the problem there in less-than-ideal way: From user's point of view I don't believe there's much downside to Is there any particular reason you need the ability to automount the default service account token? |
|
The automountServiceAccountToken flag is independent of the service account, default or explicit. |
|
This was what I did to enable it on my fork. |
I was just mentioning service account because it has a very similar problem which we had to work around, unlike in Pod and RC where we were able to just disable this behaviour.
There's certainly a way to specify service account when scheduling a pod or RC, see related docs at
I personally think that no access by default (and explicitness) is generally a good security practice, but I fully understand some other people may have different opinions. Either way the main motivation here was avoid spurious diffs as mentioned, the security is rather a (IMO positive) side effect.
Have you tried running |
|
I'm a bit confuse since you seem to talk about the automountServiceAccountToken and the service_account_name at the same time. Yes, I've been using my fork with automountServiceAccountToken = true and no problems on my local kubernetes cluster. |
|
Btw you can play with my fork easily here https://github.com/mingfang/docker-terraform |
Right, it is a bit confusing because there's a couple of actions enabled by that field, which is documented at https://kubernetes.io/docs/admin/service-accounts-admin/#service-account-admission-controller - so both service account association and volume mount are enabled by this single option. I have not inspected the container and tried accessing the API, but here's a config I was able to successfully apply which mimics the behaviour of resource "kubernetes_pod" "test" {
metadata {
name = "terraform-example"
}
spec {
service_account_name = "${kubernetes_service_account.example.metadata.0.name}"
container {
image = "nginx:1.7.9"
name = "example"
volume_mount {
mount_path = "/var/run/secrets/kubernetes.io/serviceaccount"
name = "${kubernetes_service_account.example.default_secret_name}"
read_only = true
}
}
volume {
name = "${kubernetes_service_account.example.default_secret_name}"
secret {
secret_name = "${kubernetes_service_account.example.default_secret_name}"
}
}
}
}
resource "kubernetes_service_account" "example" {
metadata {
name = "terraform-example"
}
}
I built the provider from your branch and used the following config to demonstrate the problem: resource "kubernetes_pod" "test" {
metadata {
name = "terraform-example"
}
spec {
automount_service_account_token = true
container {
image = "nginx:1.7.9"
name = "example"
}
}
}and here's what happens when you apply it: Let me know if that clears some of the confusions and whether we can close this issue now. |
|
I see the problem with the pod resource you described above, but I was testing with the replication controller resource and am not seeing any mounts at all. |
|
My point remains - it is possible to mimic the behaviour of In that context do you mind me closing this issue?
If there is a bug I'd be more than happy to hear about it and fix it, if we have a way to reproduce it. |
|
I don't see how to make this work, I'm following comment #38 (comment). Service account is created and mounted in pod, but when trying to access the kubernetes API from the pod I got Unknown user "system:serviceaccount:dev:service-account" I named the service account "service-account" and using namespace "dev". I can see that service account exists by using kubectl from my machine but from the pod using curl with the correct mounted token or kubectl I keep getting "Unknown user". |
|
Could you allow AutomountServiceAccountToken to be set explicitly while creating serviceaccount? |
|
@radeksimko correct me if I'm wrong but here's what I'm thinking: given the Additionally, I first noticed this behaviour with the new |
|
@radeksimko the approach given here doesn't seem to include the |
|
I am also running into this issue at the |
|
@radeksimko At least, you could document the behaviour and your proposed solution in the corresponding sections of Terraform docs about |
|
Not really sure why terraform folks decided to change default behavior of kubectl and the rest of Kubernetes ecosystem, without even documenting how to make it working. |
|
@onorua To address this issue and many others, I've created my own Kubernetes Provider here https://github.com/mingfang/terraform-provider-k8s. For this case it will work as expected and no work arounds are needed. |
|
@mingfang thank you very much for your help. Unfortunately that would require copying your provider to all my colleagues which may be inconvenient. |
|
@onorua Unfortunately the official Terraform Kubernetes provider currently is plagued by some questionable design decisions, that aren’t a priority to fix at the moment due to Terraform 0.12’s imminent arrival (and delays). |
|
Echoing some of the other comments above. I spent hours trying to figure out why a service account and deployment wasn't working in Terraform, but worked with no issues in kubectl - it was the AutomountServiceAccountToken being hardcoded to False in the deployment resource. At a minimum this should be documented in the Terraform docs for the resource with something noting the resource does not behave like kubectl does. I was able to use code like that provided by @radeksimko to eventually get it working. |
|
I just ran into this problem today when writing the first of our Terraform modules for our infrastructure. It's disappointing that this hasn't been fixed two years on when it actively breaks default Kubernetes behaviour. Thankfully @radeksimko's volumeMount workaround worked for us |
|
In case anyone missed it, this is really close to being resolved here: #261 |
ghost
locked and limited conversation to collaborators
Currently AutomountServiceAccountToken is hardcoded to false
https://github.com/terraform-providers/terraform-provider-kubernetes/search?utf8=✓&q=AutomountServiceAccountToken&type=
According to the Kubernetes documentation https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/, this value should either be computed or set by each pod.
The text was updated successfully, but these errors were encountered: