英文:
Does the ServiceAccount token need to remain secret?
问题
在一个Pod中，ServiceAccount令牌将自动挂载到/var/run/secrets/kubernetes.io/serviceaccount/token。有一些博客文章建议使用ServiceAccount进行服务间身份验证。
这些文章基本上建议将未修改的令牌作为HTTP头发送到被调用的服务。被调用的服务可以使用k8s.io/api/authentication Go API来验证调用者的身份。
但是令牌不需要保密吗？天真地说，我认为被调用的服务可以滥用令牌来冒充调用的服务（使用其令牌进行API调用）。
这是一个合理的担忧吗？还是K8s中有一些内置的机制确保只有挂载了令牌的Pod可以使用它进行API调用？
英文:
In a pod, a ServiceAccount token will be auto-mounted to /var/run/secrets/kubernetes.io/serviceaccount/token. There are some blog articles that suggest using ServiceAccounts to perform service to service authentication.
Those articles basically suggest sending the unmodified token to the service being called as an HTTP header. The called service can then implement validating the callers identity using k8s.io/api/authentication Go API.
But doesn't the token need to be kept secret? Naively I'd think that the called service can misuse the token to impersonate the calling service (by making API calls using its token).
Is this a legitimate concern? Or is there something build into K8s that makes sure only the pod into which the token has been mounted can use it to make API calls?
答案1
得分: 0
有几个人基本上回答了这个问题，但是使用了评论。所以让我自己来回答这个问题。
这个令牌可以用来冒充发送它的服务。甚至可以在集群外部使用它来进行 API 的身份验证。
K8S API 中似乎也没有使用公钥机制的机制，以避免暴露令牌。
总的来说，把令牌发送给其他人似乎是一个非常糟糕的主意。我建议不要使用问题中链接的博客文章中概述的方法。
英文:
A few folks basically answered the question but used comments. So let me answer the question myself.
The token can be used to impersonate the service sending it. It can even be used outside the cluster to authenticate to the API.
There also doesn't seem to be machinery in the K8S API to use public key mechanisms, to avoid having to reveal the token.
Overall, sending the token to anyone else seems like a really bad idea. I would advise not to use the approach outlined in the blog post linked to in the question.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论