Очень полезно создавать изолированные среды для разработчиков и команд, особенно для обучения.
Это особенно верно в архитектуре микросервисов, где вы захотите протестировать свое приложение в изолированной среде, прежде чем выпускать его для использования другими командами.
Это также полезно, когда рабочие нагрузки слишком велики для выполнения на одном ноутбуке (например, при тестировании алгоритмов машинного обучения).
Вы можете достичь такого уровня изоляции с Kubernetes, используя пространства имен.
Пространства имен – это способ разделить ресурсы кластера между несколькими пользователями.
В этом посте мы создадим пространство имен, а затем создадим Service Account, который имеет доступ только к этому конкретному пространству имен, используя систему контроля доступа на основе ролей (RBAC) Kubernetes.
Наконец, мы экспортируем конфигурацию, необходимую для доступа к этому пространству имен.
Предпосылки
Кластер Kubernetes с достаточным доступом для создания пространств имен и Service Account.
Создадим пространство имен ( namespace)
kubectl create namespace mynamespace
Создадим Service Account с необходимыми правамии
Откройте новый файл.
Назовем это access.yaml.
Мы собираемся создать пользователя (Service Account), Role и привязать эту роль к этому пользователю.
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: mynamespace-user
namespace: mynamespace
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: mynamespace-user-full-access
namespace: mynamespace
rules:
- apiGroups: ["", "extensions", "apps"]
resources: ["*"]
verbs: ["*"]
- apiGroups: ["batch"]
resources:
- jobs
- cronjobs
verbs: ["*"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: mynamespace-user-view
namespace: mynamespace
subjects:
- kind: ServiceAccount
name: mynamespace-user
namespace: mynamespace
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: mynamespace-user-full-access
Как видите, в определении роли мы добавляем полный доступ ко всему в этом пространстве имен, включая jobs и cronjobs.
Поскольку это роль, а не ClusterRole, она будет применяться к одному пространству имен: mynamespace.
Подробнее о ролях в Kubernetes читайте в официальной документации.
А теперь давайте создадим все это:
kubectl create -f access.yaml
Вы должны увидеть три создаваемых компонента.
Получим секреты
Первое, что нам нужно сделать сейчас, это получить имя секрета для Service Account.
Выполните следующую команду и скопируйте имя секрета:
kubectl describe sa mynamespace-user -n mynamespace
Предположим, что в этом руководстве секрет называется mynamespace-user-token-xxxxx.
Теперь нам нужно получить токены.
Для этого мы собираемся прочитать их с помощью kubectl.
Теперь, когда секреты Kubernetes закодированы в base64, нам также нужно будет их декодировать.
Вот как получить токен пользователя:
kubectl get secret mynamespace-user-token-xxxxx -n mynamespace -o "jsonpath={.data.token}" | base64 -D
А вот как получить сертификат:
kubectl get secret mynamespace-user-token-xxxxx -n mynamespace -o "jsonpath={.data['ca\.crt']}"
Создание Kube config
Теперь у нас есть все необходимое.
Осталось только создать конфигурационный файл Kube с ранее собранными данными:
apiVersion: v1
kind: Config
preferences: {}
# Define the cluster
clusters:
- cluster:
certificate-authority-data: PLACE CERTIFICATE HERE
# You'll need the API endpoint of your Cluster here:
server: https://YOUR_KUBERNETES_API_ENDPOINT
name: my-cluster
# Define the user
users:
- name: mynamespace-user
user:
as-user-extra: {}
client-key-data: PLACE CERTIFICATE HERE
token: PLACE USER TOKEN HERE
# Define the context: linking a user to a cluster
contexts:
- context:
cluster: my-cluster
namespace: mynamespace
user: mynamespace-user
name: mynamespace
# Define current context
current-context: mynamespace
Примечание. Другой способ написать конфиг – напрямую использовать kubectl.
См. Справку по команде kubectl config.
Теперь вы можете передать этот файл конфигурации Kube пользователю, которому вы хотите предоставить доступ.
