У новой учетной записи службы Kubernetes есть разрешения администратора кластера

Я наблюдаю странное поведение недавно созданных учетных записей служб 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

Запуск этого ^ в качестве сценария оболочки дает 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 запросов с использованием вновь созданной конфигурации.

Ниже приведен пример JWT учетной записи службы test-sa, встроенной в config:

{
  "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/v1 и rbac.authorization.k8s.io/v1beta1 в выводе kubectl api-versions | grep rbac, как это предлагается в этот пост. Примечательно, что kubectl cluster-info dump | grep authorization-mode, как предлагается в другом ответе на тот же вопрос, не отображает вывод. Может ли это означать, что RBAC на самом деле не включен?
• У моего пользователя есть cluster-admin ролевые привилегии, но я не ожидал, что они будут перенесены в учетные записи служб, созданные с его помощью.
• Мы запускаем наш кластер на GKE.
• Насколько мне известно, у нас нет неортодоксальных ролей или привязок RBAC в кластере, которые могли бы вызвать это. Я мог что-то упустить или вообще не знаю о конфигурациях K8s RBAC, которые могли бы вызвать это.

Правильно ли я предполагаю, что вновь созданные учетные записи служб должны иметь чрезвычайно ограниченный доступ к кластеру, и описанный выше сценарий не может быть возможен без разрешающих привязок ролей, прикрепленных к новой учетной записи службы? Есть какие-нибудь мысли о том, что здесь происходит, или о способах ограничения доступа к test-sa?