容器内访问kubeconfig的非卷挂载方式及RBAC相关问题

不使用卷挂载传递kubeconfig的可行实现 #

你可以选择以下几种不需要手动挂载本地kubeconfig卷的方案：

• 构建自定义镜像时内置kubeconfig
  bitnami/kubectl默认读取容器运行用户家目录下的~/.kube/config路径，你可以在自定义Dockerfile中直接将本地kubeconfig文件COPY到该路径，构建完成后启动容器就会自动读取配置。注意要给镜像内的1001默认运行用户添加该文件的读权限，否则会出现权限报错。这种方式会把集群访问凭证固化在镜像层，存在泄露风险，仅建议本地临时测试使用。
• 通过环境变量传入配置内容
  kubectl支持读取KUBECONFIG环境变量指定的配置文件路径，你可以在启动容器时将本地kubeconfig的内容做base64编码后通过环境变量传入，容器启动入口处先把内容解码到临时文件路径，再执行kubectl命令即可，参考启动命令：

  docker run -e KUBECONFIG_TMP=$(base64 -w 0 ~/.kube/config) \
    bitnami/kubectl:latest \
    bash -c "echo $KUBECONFIG_TMP | base64 -d > /tmp/kubeconfig && export KUBECONFIG=/tmp/kubeconfig && kubectl get ns"
  

  这种方式不会把凭证写入镜像层，安全性比内置到镜像更高，注意不要在命令日志中打印明文凭证内容。
• 集群内运行时使用自动挂载的ServiceAccount凭证
  如果你的kubectl容器本身就调度在目标Kubernetes集群内运行，集群默认会自动把当前Pod绑定的ServiceAccount的访问令牌挂载到容器内/var/run/secrets/kubernetes.io/serviceaccount/路径，kubectl会自动识别该路径下的凭证信息，完全不需要你手动提供本地kubeconfig。

仅配置Role/RoleBinding能否免挂载kubeconfig执行操作 #

不能。
Role和RoleBinding只是Kubernetes RBAC体系里的权限规则定义，作用是约定某个主体（用户、组、ServiceAccount）拥有哪些资源的操作权限，本身不会给你的容器自动注入访问apiserver所需的凭证信息。
kubectl执行任何操作的前提是先拿到合法的访问凭证（包含apiserver地址、集群CA证书、身份校验用的令牌/客户端证书），RBAC规则只是在你持有合法凭证发起请求时，判断你有没有权限执行对应操作，完全不能替代凭证本身。
如果是前面提到的集群内运行容器的场景，你给Pod绑定的ServiceAccount配置好对应的Role、RoleBinding之后，确实不需要手动挂载本地kubeconfig就能执行kubectl apply、kubectl delete这类操作，但本质是使用了集群自动挂载的ServiceAccount令牌作为访问凭证，不是无凭证访问，且RoleBinding必须正确绑定到Pod实际使用的ServiceAccount上权限才会生效。

内容的提问来源于stack exchange，提问作者anonymous user