• Kubernetes Documentation -> Reference -> API Access Control -> Authenticating

• Как работает аутентификация в Kubernetes: ServiceAccount и RBAC
• A Hands-On Guide to Kubernetes RBAC With a User Creation
• Kubernetes Documentation kubectl config set-credentials

• Where can I get a list of Kubernetes API resources and subresources?
• Node/Proxy in Kubernetes RBAC
• How to grant access to specify namespace in kubernetes dashboard?
• Namespace Permissions (Kubernetes RBAC-based)
• Kubernetes RBAC Port Forward

• Implementing and Verifying Kubernetes Service Accounts: A Step-by-Step Guide

• Kubernetes — это решение, превращающее Linux сервера в кластер, и, как Linux является многопользовательской, многозадачной операционной системой, так и Kubernetes позволяет множеству пользователей и приложений работать в одном кластере, безопасно разделяя его ресурсы
• На нашем вебинаре Вы узнаете как настраивать права доступа в Kubernetes на примерах практических, полезных задач

• Создать учетную запись и файл конфигурации с правами для подключения к приложениям, администрированию ресурсов выделенного Namespace и всего кластера Kubernetes
• Использовать учтённые записи приложений в Kubernetes для доступа к API

• Тэги: Kubernetes, ServiceAccout, RBAC

• Система Kubernetes

• Cloud native distributed block storage for Kubernetes longhorn
• rancher local-path-provisioner и кластер CloudNativePG для Keycloak в Kubernetes
• Kubernetes Dashboard без ServiceAccout

• Linux Инсталяция системы в конфигурации Desktop и Установка и инициализация клиента FreeIPA

kube1:~# cat ~/.kube/config

kube1:~# echo LS0tLS1CR...LS0tLS0K | base64 -d

• Certificate Decoder

kube1:~# kubectl auth whoami

• Использование сертификатов

• Для примера можно использовать ServiceAccout из темы Kubernetes Dashboard в Namespace default
• Показать временные и long-lived Bearer Token для ServiceAccount

• Инструмент командной строки kubectl

• Создание файла конфигурации kubectl

• Предоставление доступа к services/proxy в Namespace

• Предоставление полного доступа к Namespace

• Запускаем pod my-debian (Базовые объекты k8s) в my-ns (создать, если нет)

• Поиск предоставленных ролей для учетной записи

• Предоставление доступа к services/port-forward в Cluster

• Предоставление полного доступа к Kubernetes Cluster

• Поиск предоставленных кластерных ролей для учетной записи

• Возвращаемся на Вариант 2.2 Использование ServiceAccount

kube1:~/users# kubectl delete clusterrolebindings admin-user

kube1:~/users# kubectl delete serviceaccounts admin-user

• Используем ранее запущенное приложение (Базовые объекты k8s) в my-ns

kube1:~/users# kubectl -n my-ns describe pod my-debian | grep -i account

kube1:~/users# kubectl -n my-ns exec -ti pods/my-debian -- bash

root@my-debian:/# apt update && apt install kubectl

• Создание файла конфигурации kubectl

kube1:~/users# kubectl auth can-i get pods --as=system:serviceaccount:my-ns:default

kube1:~/users# cat sa-default-cluster-admin.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: sa-default-cluster-admin
subjects:
- kind: ServiceAccount
  name: default
  namespace: my-ns
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

kube1:~/users# kubectl apply -f sa-default-cluster-admin.yaml

Проверяем доступ к API из приложения

kube1:~/users# kubectl delete -f sa-default-cluster-admin.yaml

kube1:~/users# kubectl -n my-ns delete pod my-debian                                                      

1. Куда и через сколько исчезает “kubectl get csr” после “approve” ?

user1@client1:~$ rm -v user1*

user1@client1:~$ rm -rfv .kube/

kube1:~# rm -rfv users/

user1@client1:~$ cp -rv .kube.iodc/ .kube/

• Открываем браузер
• Подколючемся к giltab через keycloak

user1@client1:~$ kubelogin

user1@client1:~$ kubectl auth whoami

• Предоставление полного доступа к Kubernetes Cluster

https://medium.com/@amirhosseineidy/kubernetes-authentication-with-keycloak-oidc-63571eaeed61

https://vlasov.pro/ru/p/kubernetes-oidc/

https://github.com/int128/kubelogin

https://timeweb.cloud/docs/k8s/connect-oidc-provider-to-cluster

? https://www.talkingquickly.co.uk/setting-up-oidc-login-kubernetes-kubectl-with-keycloak

Email verified

kube1:~/users# vim /etc/kubernetes/manifests/kube-apiserver.yaml
...
spec:
  containers:
  - command:
    - kube-apiserver
    - --oidc-issuer-url=https://keycloak.corp13.un/realms/corp13
    #- --oidc-client-id=account
    - --oidc-client-id=any-client
    - --oidc-username-claim=email
    #- --oidc-username-claim=preferred_username
    - --oidc-groups-claim=groups
...

kube1:~/users# kubectl -n kube-system logs Pod/kube-apiserver-kube1
...
E1203 05:22:46.412571       1 authentication.go:73] "Unable to authenticate the request" err="[invalid bearer token, oidc: verify token: oidc: expected audience \"any-client\" got [\"account\"]]"
...

user1@client1:~$ cat .kube/config
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: ...
    server: https://192.168.13.221:6443
  name: cluster.local
contexts:
- context:
    cluster: cluster.local
    user: user1
  name: default-context
current-context: default-context
kind: Config
preferences: {}
users:
- name: user1
  user:
    auth-provider:
      config:
        client-id: any-client
        client-secret: anystring
        grant-type: password
        #id-token: 
        idp-issuer-url: https://keycloak.corp13.un/realms/corp13
        #refresh-token: 
      name: oidc

https://habr.com/ru/companies/slurm/articles/711868/|Журналы аудита Kubernetes: лучшие практики и настройка

kube1:~# cat /etc/kubernetes/audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:

  - level: None
    verbs: ["get", "watch", "list"]

  - level: None
    resources:
    - group: "" # core
      resources: ["events"]

  - level: None
    users:
    - "system:kube-scheduler"
    - "system:kube-proxy"
    - "system:apiserver"
    - "system:kube-controller-manager"
    - "system:serviceaccount:gatekeeper-system:gatekeeper-admin"

  - level: None
    userGroups: ["system:nodes"]

  - level: RequestResponse

kube1:~# kubectl apply -f /etc/kubernetes/audit-policy.yaml --dry-run=client
error: resource mapping not found for name...

https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/|Kubernetes Documentation - Auditing

kube1:~# vim /etc/kubernetes/manifests/kube-apiserver.yaml
...
    - --audit-log-maxage=1
...

kube1:~# date

kube1:~# journalctl -u kubelet --since "2025-12-01 10:19:00" | cat | less
...
..."SyncLoop REMOVE" source="file" pods=["kube-system/kube-apiserver-kube1"]...
...
..."Killing container with a grace period" pod="kube-system/kube-apiserver-kube1"...


kube1:~# tail -f /var/log/kubernetes/audit/audit.log | jq

user1@client1:~$ kubectl -n my-apwebd-ns delete pod my-webd-<TAB>

Создаём группы и пользователей под Kubernetes
У нас уже есть настроенная Freeipa
FreeIPA — это серверная система для централизованного управления пользователями, группами, доступами, сертификатами и DNS в инфраструктуре.
Заходим на freeipa, через web интерфейс или же можно воспользоваться консолью
https://ipa-server-1.teach.local/
ssh root@192.168.100.252
Мы воспользуемся консолью чтобы сэкономить время
Но предварительно на web проверим что нет групп для  кубернетис
Используем команду kinit чтобы получить билет Kerberos и введем команды для создания

ipa group-add k8s-cluster-admins \
  --desc="Kubernetes cluster admins"

ipa group-add k8s-ns-core-test-view \
  --desc="View access to core-test namespace"

ipa group-add k8s-ns-core-test-admin \
  --desc="Admin access to core-test namespace"
ipa group-add k8s-ns \
--desc="Access only view all ns"

Теперь обновим страницу с группами и увидим созданные нами группы
Далее Создаём тестового пользователя
ipa user-add ivan \
  --first=Ivan \
  --last=Petrov \
  --password

ipa user-add sergey \
  --first=Sergey \
  --last=Admin \
  --password


ipa user-add kirill \
  --first=Kirill \
  --last=Viewer \
  --password
ipa user-add ira \
  --first=Irina\
  --last=Viewer \
  --password


Далее попросят ввести пароль
Вводим пароль 123456
И подтверждаем
Конечно такой пароль только для демонстрации а не для продового использования
Добавляем пользователя в группу

ipa group-add-member k8s-ns-core-test-view --users=ivan
ipa group-add-member k8s-ns-core-test-admin --users=kirill
ipa group-add-member k8s-ns --users=ira
ipa group-add-member k8s-cluster-admins --users=sergey

Далее Аккаунт для Dex в FreeIPA (LDAP bind user)
Dex должен логиниться в LDAP FreeIPA с каким-то пользователем.

ipa user-add dex-bind \
  --first=Dex \
  --last=Bind \
  --password

Проверяем LDAP-доступ к FreeIPA
Чтобы  убедится что dex сможет залогинется


Зайдем на сервер c которого будем управлять k8s и выполнил поиск нашего пользователя
ssh root@192.168.100.249

ldapsearch -x   -H ldap://192.168.100.252:389   -D "uid=dex-bind,cn=users,cn=accounts,dc=teach,dc=local"   -W   -b "cn=users,cn=accounts,dc=teach
,dc=local"   "(uid=ivan)"

Подключимся пользователем dex-bind
И поищем созданного нами пользователя ivan
Видим что все ок данные получаем

Далее настроим установим и настроим dex
Для этого будем использовать helm
Helm — это менеджер пакетов для Kubernetes, грубо говоря:
«apt/yum для Kubernetes


Нам понадобится серт мэнеджер для выпуска сетификатов и ингресс контроллер


helm repo add jetstack https://charts.jetstack.io
helm repo update

helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --set crds.enabled=true


helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

helm install ingress-nginx ingress-nginx/ingress-nginx \
  -n ingress-nginx --create-namespace \
  --set controller.ingressClassResource.name=nginx \
  --set controller.ingressClassByName=true \
  --set controller.hostNetwork=true \
  --set controller.dnsPolicy=ClusterFirstWithHostNet \
  --set controller.kind=DaemonSet \
  --set controller.service.type=NodePort


Перезагружаем сервера



Начиная с новых версий FreeIPA, в нём есть ACME-сервер
ACME-server — это “серверная сторона автоматики сертификатов”.
ACME (Automatic Certificate Management Environment) — это протокол, по которому:
клиент (cert-manager, acme.sh, lego, certbot и т.п.)
общается с CA (центром сертификации) через ACME-server
чтобы автоматически выпускать и обновлять TLS-сертификаты.
Примеры ACME-серверов:
Let’s Encrypt (самый известный; их сервер — Boulder)



ipa-acme-manage enable
ipa-acme-manage status


появится эндпоинт

https://ipa-server-1.teach.local/acme/directory

curl -vk https://ipa-server-1.teach.local/acme/directory

далее получаем сертифкат freeipa корневой
идем на сервер freeipa

sudo cat /etc/ipa/ca.crt > ipa-ca.crt
далее переводим в base64
base64 -w0 ipa-ca.crt > ipa-ca.b64

затем нам нужен ClusterIssuer

ClusterIssuer — это кластерный “поставщик сертификатов” в cert-manager, который виден во всех неймспейсах Kubernetes.
Говоря по-человечески:
cert-manager — это оператор, который умеет автоматически выпускать и обновлять сертификаты.
ClusterIssuer/Issuer — это “настройка, куда идти за сертификатом и как его получать”.

Файл issuser.txt
И caBundle ПОДСТАВЬ_ЗДЕСЬ_СТРОКУ_ИЗ_ipa-ca.b64


apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: freeipa-acme
spec:
  acme:
    email: admin@teach.local
    server: https://ipa-server-1.teach.local/acme/directory
    privateKeySecretRef:
      name: freeipa-acme-account-key

    # ВАЖНО: одна длинная строка из ipa-ca.b64
    caBundle: ПОДСТАВЬ_ЗДЕСЬ_СТРОКУ_ИЗ_ipa-ca.b64

    solvers:
      - http01:
          ingress:
            ingressClassName: nginx


1. Выпускаем сертификат для Dex
Сделаем Certificate, который:
использует твой ClusterIssuer freeipa-acme;
кладёт сертификат в Secret dex-tls в namespace dex.


Для начала нам нужна dns запись
Посмотрим какие ip у серверов k8s
kubectl get nodes -o wide
В freeipa

ipa dnsrecord-add teach.local dex --a-rec=192.168.100.229
это адрес одной из наших нод

Создаем нейаспейс
kubectl create ns dex

затем применяем файл  с запросом сетификата
файл certificate.txt

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: dex-cert
  namespace: dex
spec:
  secretName: dex-tls
  dnsNames:
    - dex.teach.local
  issuerRef:
    name: freeipa-acme
    kind: ClusterIssuer

Добавляем репозиторий  с dex


helm repo add dex https://charts.dexidp.io
helm repo update

Качаем локально хелм чарт
helm pull dex/dex

У нас скачивается архив с helm чартом
ls
далее распаковываем архив
tar -xvf dex-0.24.0.tgz
переходим в каталог
cd dex


и тут нас интересует файл values.yaml
vi values.yml
открываем файл и редактируем берем пример из файла config.txt
нужно сгенерить секрет
openssl rand -hex 32
и заменить SUPER-SECRET-STRING на полученный секрет
Создаем секрет

kubectl -n dex create secret generic dex-ldap-bind \
  --from-literal=DEX_LDAP_BIND_DN='uid=dex-bind,cn=users,cn=accounts,dc=teach,dc=local' \
  --from-literal=DEX_LDAP_BIND_PW='123456'


сохраняем и применяем
helm upgrade --install dex .   -n dex   -f values.yaml
Тест с любой машины, где dex.teach.local резолвится в IP ноды:
curl -vk https://dex.teach.local/dex/.well-known/openid-configuration
Кладём CA FreeIPA на мастер
Переходим на мастер ноду
ssh root@192.168.100.230
scp root@ipa-server-1.teach.local:/etc/ipa/ca.crt /root/ipa-ca.crt
sudo cp /root/ipa-ca.crt /etc/kubernetes/ssl/dex-ca.crt

Затем правим настройки kubeapi

vi /etc/kubernetes/manifests/kube-apiserver.yaml

Добавляем

- --oidc-issuer-url=https://dex.teach.local/dex
- --oidc-client-id=dex-k8s-authenticator
- --oidc-username-claim=email
- --oidc-groups-claim=groups
- --oidc-ca-file=/etc/kubernetes/ssl/dex-ca.crt

Kubeapi сам перезагрузится

Если все ок то в браузере перейдя по ссылке увидим ответ от dex
https://dex.teach.local/dex/.well-known/openid-configuration

отлично dex установлен но Dex сам по себе — только  (OIDC-провайдер).
Страничку, где после логина рисуется готовый kubeconfig, делает другой сервис — dex-k8s-authenticator.


kubectl create namespace dex-auth


Добавляем на freeipa dns запись

ipa dnsrecord-add teach.local auth --a-ip-address=192.168.100.229
ipa dnsrecord-show teach.local auth
выпускаем сертификат для web интерфейса
kubectl apply -f ../certificate-auth.yaml

Ставим dex-k8s-authenticator

helm repo add wiremind https://wiremind.github.io/wiremind-helm-charts
helm repo update
helm pull wiremind/dex-k8s-authenticator

tar -xvf  dex-k8s-authenticator-1.7.0.tgz

cd dex-k8s-authenticator

vi values.yaml

в вэлюсах указываем наши данные
вначале копируем содержимое файла certificate-auth.txt

secret: тут должен совпадать с секретов в values dex
далее добавить CA Freeipa в файл конфига
caCerts:
  enabled: true
  secrets:
    - name: ipa-ca
      filename: ipa-ca.crt
      value: |-


идем на сервер Freeipa
выполняем команду чтобы получить серт в base64
cat /etc/ipa/ca.crt | base64 -w0 > ipa-ca.b64


в k8s_ca_pem:
указываем CA кубернетис
идем на ноду мастера k8s

cat /etc/kubernetes/ssl/ca.crt

helm upgrade --install dex-auth .   -n dex-auth   -f values.yaml

Теперь нас необходимо связать группы в k8s и freeipa
Применяем манифесты для добавления кластер ролей

kubectl create ns core-test-admin
kubectl create ns core-test-view

проверяем заходим на https://auth.teach.local/

пробуем залогинится под польз кто админ

Заходим на другой сервер и проверяем команды которые нам дал dex

ssh root@192.168.100.227

Вводим команды из web интерфейса

И пробуем подключиться

Далее запускаем тестовые поды в наших ns

Применяем файл  test-pod.txt


И тестируем права

Пробуем заходить разными польз

Если не пускает польз когда у него права только на один ns то надо дать права на просмотр.