我正在从新创建的Kubernetes服务帐户中遇到奇怪的行为。看来他们的令牌在我们的集群中提供了无限的访问权限。
如果我创建一个新的名称空间,在该名称空间内创建一个新的服务帐户,然后在新的kube配置中使用该服务帐户的令牌,则能够执行集群中的所有操作。
# SERVER is the only variable you'll need to change to replicate on your own cluster
SERVER=https://k8s-api.example.com
NAMESPACE=test-namespace
SERVICE_ACCOUNT=test-sa
# Create a new namespace and service account
kubectl create namespace "${NAMESPACE}"
kubectl create serviceaccount -n "${NAMESPACE}" "${SERVICE_ACCOUNT}"
SECRET_NAME=$(kubectl get serviceaccount "${SERVICE_ACCOUNT}" --namespace=test-namespace -o jsonpath='{.secrets[*].name}')
CA=$(kubectl get secret -n "${NAMESPACE}" "${SECRET_NAME}" -o jsonpath='{.data.ca\.crt}')
TOKEN=$(kubectl get secret -n "${NAMESPACE}" "${SECRET_NAME}" -o jsonpath='{.data.token}' | base64 --decode)
# Create the config file using the certificate authority and token from the newly created
# service account
echo "
apiVersion: v1
kind: Config
clusters:
- name: test-cluster
cluster:
certificate-authority-data: ${CA}
server: ${SERVER}
contexts:
- name: test-context
context:
cluster: test-cluster
namespace: ${NAMESPACE}
user: ${SERVICE_ACCOUNT}
current-context: test-context
users:
- name: ${SERVICE_ACCOUNT}
user:
token: ${TOKEN}
" > config
将^作为shell脚本运行会在当前目录中产生config
。问题是,使用该文件,我可以读取和编辑集群中的所有资源。我希望新创建的服务帐户没有权限,除非我通过RBAC明确授予它们。
# All pods are shown, including kube-system pods
KUBECONFIG=./config kubectl get pods --all-namespaces
# And I can edit any of them
KUBECONFIG=./config kubectl edit pods -n kube-system some-pod
我尚未向新创建的服务帐户添加任何角色绑定,因此我希望它会使用新生成的配置接收所有kubectl
查询的访问拒绝响应。
下面是嵌入在config
中的test-sa服务帐户的JWT的示例:
{
"iss": "kubernetes/serviceaccount",
"kubernetes.io/serviceaccount/namespace": "test-namespace",
"kubernetes.io/serviceaccount/secret.name": "test-sa-token-fpfb4",
"kubernetes.io/serviceaccount/service-account.name": "test-sa",
"kubernetes.io/serviceaccount/service-account.uid": "7d2ecd36-b709-4299-9ec9-b3a0d754c770",
"sub": "system:serviceaccount:test-namespace:test-sa"
}
要考虑的事情...
rbac.authorization.k8s.io/v1
时,群集中的rbac.authorization.k8s.io/v1beta1
输出中的kubectl api-versions | grep rbac
。值得注意的是,如对同一问题的另一个答案所建议,kubectl cluster-info dump | grep authorization-mode
不显示输出。这是否表明RBAC实际上并未启用?cluster-admin
个角色特权,但是我不希望这些特权继续使用它创建的服务帐户。在我的假设中,我是否纠正了新创建的服务帐户应具有极其有限的群集访问权限的情况,并且在没有将许可的角色绑定附加到新服务帐户的情况下,上述方案不可行吗?对这里发生的事情有任何想法,或者我可以限制对test-sa的访问的方式吗?
答案 0 :(得分:1)
您可以通过运行命令检查服务帐户的权限
kubectl auth can-i --list --as=system:serviceaccount:test-namespace:test-sa
如果您在下面的输出中看到默认情况下服务帐户获得的权限非常有限。
Resources Non-Resource URLs Resource Names Verbs
selfsubjectaccessreviews.authorization.k8s.io [] [] [create]
selfsubjectrulesreviews.authorization.k8s.io [] [] [create]
[/api/*] [] [get]
[/api] [] [get]
[/apis/*] [] [get]
[/apis] [] [get]
[/healthz] [] [get]
[/healthz] [] [get]
[/livez] [] [get]
[/livez] [] [get]
[/openapi/*] [] [get]
[/openapi] [] [get]
[/readyz] [] [get]
[/readyz] [] [get]
[/version/] [] [get]
[/version/] [] [get]
[/version] [] [get]
[/version] [] [get]
答案 1 :(得分:1)
我无法在测试实验室中的三个不同的K8S版本(包括v1.15.3,v1.14.10-gke.17,v1.11.7-gke.12-使用基本身份验证)上重现您的问题启用)。
不幸的是,基于令牌的登录活动未记录在GKE集群的Cloud Logs控制台的AuditLogs中:(。
据我所知,仅记录通过Google Cloud进行的数据访问操作(使用kubectl
提供程序基于AIM = google auth
)。
如果RBAC允许您的"test-sa"
服务帐户执行特定操作,我仍将尝试研究您的GKE群集的Audit Logs。也许以某种方式将您的服务帐户映射到google service account一个帐户,并因此被授权。
您随时可以与GCP的官方支持渠道联系,以进一步解决您的不寻常案件。
答案 2 :(得分:0)
事实证明,cluster-admin
绑定到ClusterRoleBinding
组中的内容过于宽松。这导致我们集群中的所有服务帐户都具有system:serviceaccounts
特权。
似乎在集群生命的早期某个地方创建了以下cluster-admin
:
ClusterRoleBinding
警告:切勿将此规则应用于您的集群☝️
此后,我们已删除了这一过于宽松的规则,并为所有服务帐户权限分配了权限。
谢谢那些为这个问题提供有用答案和评论的人。他们对于确定此问题很有帮助。这是一个非常危险的RBAC配置,我们很高兴能解决它。