使用ServiceAccount解决pod自动读取k8s凭证时的错误总结

文章讲述了在项目中使用k8s的in-cluster配置时遇到的两个问题:一是ServiceAccount权限不足,二是kubevirtAPI访问受限。通过分析源码,作者解决了这些问题,强调了权限管理和API密钥管理的重要性。
摘要由CSDN通过智能技术生成

使用背景

在做项目时,一开始使用的是通过将k8s的config文件下载到项目中进行pod的权限等验证。当k8s挂了,重新部署时,往往需要重新下载config,且明文放在项目中也不安全。

config.load_kube_config(config_file=xxx)

将上述代码改为如下代码进行自动读取k8s配置进行权限认证等

config.load_incluster_config()

但需要结合ServiceAccount 和 clusterrole等进行权限的绑定和赋予
在修改后,项目部署是遇到了如下的几个问题:

问题和解决总结

问题1

问题描述:
HTTP response body: {“kind”:“Status”,“apiVersion”:“v1”,“metadata”:{},“status”:“Failure”,“message”:“services is forbidden: User “system:serviceaccount:xxxx” cannot create resource “services” in API group “” in the namespace “default””,“reason”:“Forbidden”,“details”:{“kind”:“services”},“code”:403}

分析:
看到User “system:serviceaccount:xxxx” ,起码可以判断出service account已生效。从后面的报错来判断可能是权限不够,在ClusterRole的rules中先赋予全部权限进行测试

解决方案:
在这里插入图片描述
问题解决!但权限的控制需要解决项目来做控制。

问题2

问题描述:
HTTP response body: {“kind”:“Status”,“apiVersion”:“v1”,“metadata”:{},“status”:“Failure”,“message”:“virtualmachines.kubevirt.io is forbidden: User “system:anonymous” cannot create resource “virtualmachines” in API group “kubevirt.io” in the namespace “default””,“reason”:“Forbidden”,“details”:{“group”:“kubevirt.io”,“kind”:“virtualmachines”},“code”:403}

分析:
此问题和问题1类似,只是是针对kubvirt的,该错误是困扰最久的,在虾哥的帮助下,从kubevirt的源码发现的错误由来

解决
通过追踪kubevirt的源码,发现没有把k8s的api_key的值读到kubevirt中。修改kubevirt源码中default_api.py中全部的auth_settings = []为auth_settings = [‘BearerToken’],这样Configuration对象之前获取的token等凭证可以传入到http请求的head参数中,才不会出现匿名用户权限不够的问题

  • 11
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值