问题描述
在Kubernetes中创建ServiceAccount时，也会创建一个秘密。此机密包含ServiceAccountToken。此令牌可以在CI管道中使用，甚至可以在kubectl和其他访问群集的地方使用。 假设公司中的开发人员为自己复制了此令牌（没人知道），并且在他离开公司后，他仍然可以访问我们的Kubernetes集群。我想限制他的访问权限。我该怎么办？
解决方法
从安全的角度来看，使用服务帐户从群集外部使用kubectl或CI / CD系统与kubernetes群集进行交互并不是最佳方法。您应该使用authenticating proxy，其中将短暂JWT令牌的生成和轮换委托给外部OpenId / oAuth投诉授权系统。
服务帐户只能在群集中运行的Pod中使用，并且可以通过RBAC角色和角色绑定来限制服务帐户的授权。请记住，当前服务帐户令牌不会被kubernetes轮换。
,假设公司中的开发人员为自己复制此令牌（没有人知道），并且在他离开公司后，他仍然可以访问我们的Kubernetes集群。我想限制他的访问权限。我该怎么办？
是的，这是您必须减轻的风险。
在Kubernetes中，您现在可以使用仅在短时间内有效的令牌，例如一小时。如果可以，请使用Service Account from a projected volume。另请参见No more forever tokens。实际上，从安全的角度来看，我认为这是大多数服务帐户使用的更好方法。
如果您使用Kubernetes原生CI / CD管道，例如通过使用Tekton，您可以使用定期更新的这些较新的令牌进行部署。
如果您是从群集外部部署的，则@Arghya Sadhu通过使用身份验证代理提供了一个不错的选择。
在云提供商处使用Kubernetes吗？
如果您在云提供商处使用Kubernetes并从集群外部的CI / CD进行部署，它们通常具有联合身份解决方案，例如AWS IAM roles for EKS service accounts或Google Workload Identity for GKE