gpt4 book ai didi

kubernetes - 新的 Kubernetes 服务帐户似乎具有集群管理员权限

转载 作者:行者123 更新时间:2023-12-02 11:39:02 25 4
gpt4 key购买 nike

我在新创建的 Kubernetes 服务帐户中遇到了奇怪的行为。他们的 token 似乎在我们的集群中提供了无限的访问权限。

如果我创建一个新的命名空间,在该命名空间内创建一个新的服务账户,然后在新的 kube 配置中使用该服务账户的 token ,我就能够在集群中执行所有操作。

# 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

我没有向新创建的服务帐户添加任何角色绑定(bind),因此我希望它使用新生成的配置接收所有 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 似乎在集群中启用了,因为我看到 rbac.authorization.k8s.io/v1rbac.authorization.k8s.io/v1beta1kubectl api-versions | 的输出中grep rbac 按照 this post 中的建议.值得注意的是 kubectl cluster-info dump | grep authorization-mode,正如对同一问题的另一个答案所建议的,不显示输出。这是否表明 RBAC 实际上并未启用?
  • 我的用户拥有 cluster-admin 角色权限,但我不希望这些权限会转移到使用它创建的服务帐户。
  • 我们在 GKE 上运行我们的集群。
  • 据我所知,我们在集群中没有任何非正统的 RBAC 角色或绑定(bind)会导致这种情况。我可能遗漏了一些东西,或者我通常不知道会导致这种情况的 K8s RBAC 配置。

我的假设是否正确,即新创建的服务帐户应该具有极其有限的集群访问权限,如果没有将许可角色绑定(bind)附加到新服务帐户,上述情况就不可能发生?对这里发生的事情有什么想法,或者我可以限制 test-sa 访问的方法吗?

最佳答案

可以通过命令查看服务账号的权限

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]

关于kubernetes - 新的 Kubernetes 服务帐户似乎具有集群管理员权限,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/60570470/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com