赞
踩
–as=system:serviceaccount:demo-rbac:demo-user模拟某组件的某sa
在 Kubernetes 中,kubectl 命令提供了一个 --as 参数,用于临时模拟以指定的用户身份执行命令。这个功能可以帮助你测试和验证某个用户或服务账户的权限。
解释:
kubectl get role -n demo-rbac --as=system:serviceaccount:demo-rbac:demo-user
kubectl get role -n demo-rbac:
–as=system:serviceaccount:demo-rbac:demo-user:
demo-user
这个服务账户的身份执行命令,而不是以当前用户
的身份执行。什么是当前用户的身份? 我们知道一个命名空间A内可以有若干个sa,但是A内的pod只能指定一个sa,当我们kubectl exec 命令进入pod后,执行
curl -k -H “Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)” https://kubernetes.default.svc/api/v1/namespaces/demo-rbac/pods
虽然没有指定sa,但是错误信息 “message”: "forbidden: User “system:serviceaccount:demo-rbac:demo-user” 中却提示我们 使用了 sa=demo-user
,也就是说整个pod内的任意进程访问kube api,自动携带的身份就是pod的sa属性
含有错误信息的示例,前提是这个sa确实没有权限,或者替换成其他的没有权限的url资源:
curl -k -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://kubernetes.default.svc
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "forbidden: User \"system:serviceaccount:demo-rbac:demo-user\" cannot get path \"/\": user does not have read access to the namespace",
"reason": "Forbidden",
"details": {
},
"code": 403
}
一般来说 --as 使用用于在主机上执行kube命令,进行验证某个权限功能,此时不必进入到pod中,否则,就需要像前面章节中提到的kubectl exec 进入到pod后,再执行命名
示例场景
假设你有一个服务账户 demo-user,你想验证这个服务账户是否有权限在 demo-rbac 命名空间中列出所有 Role 资源。使用以下命令:
kubectl get role -n demo-rbac --as=system:serviceaccount:demo-rbac:demo-user
如果这个服务账户有权限,你会看到 demo-rbac 命名空间中的 Role 列表。
如果没有权限,命令会失败,并提示相关的权限错误信息。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。