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