Kubernetes Secrets, RBAC и Vault: Difference between revisions

From wiki.baghirzade.pro
Jump to navigation Jump to search
VisualWikitext
Created page with "=== 1. ConfigMap vs Secret === * '''ConfigMap:''' Используется для хранения обычных конфигураций (динамических конфигов). Если менять их внутри имиджа (Dockerfile), придется каждый раз пересобирать имидж. ConfigMap позволяет делать это динамически. * '''Secret:''' Используется для чувствительных..."
 
No edit summary
 
Line 25: Line 25:
kubectl get secret secret-1 -o yaml
kubectl get secret secret-1 -o yaml
</syntaxhighlight>
</syntaxhighlight>
* '''Декодирование секрета (Linux way):'''
<pre<syntaxhighlight lang="bash">
echo "ЗНАЧЕНИЕ_ИЗ_YAML" | base64 -d
</syntaxhighlight>
* '''Создание секрета из файла:'''
<syntaxhighlight lang="bash">
kubectl create secret generic db-secret --from-file=db.properties
</syntaxhighlight>
=== 4. Доступ к приватным регистрам (Docker Registry Secret) ===
Если имидж лежит в приватном '''Nexus''' или '''Harbor''', Kubernetes не сможет его скачать без пароля.
* '''Решение 1:''' Создать секрет типа <code>docker-registry</code> и указать его в деплойменте в поле <code>imagePullSecrets</code>.
* '''Решение 2 (DevOps way):''' Настроить логин прямо на уровне '''Container Runtime''' (на воркер-нодах), чтобы не прописывать секрет в каждом манифесте.
=== 5. Безопасность и HashiCorp Vault ===
Так как стандартные секреты K8s не очень безопасны (Base64 легко взломать), профессионалы используют '''Vault''':
* '''Sidecar-контейнер (Vault Agent):''' Рядом с основным приложением в поде запускается агент. Он берет токен, идет в Vault, забирает пароль и подкладывает его приложению.
* '''TTL (Time To Live):''' Токены в Vault живут недолго (например, 15 минут), что гораздо безопаснее статичных паролей.
=== 6. RBAC (Role-Based Access Control) ===
Это система управления доступом. Она отвечает на вопрос: "Кто и что может делать?".
* '''Authentication (Кто ты?):''' Проверка сертификата или токена.
* '''Authorization (Что тебе можно?):''' Проверка прав (RBAC).
* '''Admission Control:''' Финальная проверка (например, запрет на запуск подов без лимитов ресурсов).
'''Основные объекты RBAC:'''
* '''Role / ClusterRole:''' Список правил (например: можно только "геттить" поды).
* '''RoleBinding / ClusterRoleBinding:''' Связка "Роль + Пользователь/Сервис-аккаунт".

Latest revision as of 21:40, 6 January 2026

1. ConfigMap vs Secret

  • ConfigMap: Используется для хранения обычных конфигураций (динамических конфигов). Если менять их внутри имиджа (Dockerfile), придется каждый раз пересобирать имидж. ConfigMap позволяет делать это динамически.
  • Secret: Используется для чувствительных данных (пароли, TLS-сертификаты).
  • Главное отличие: ConfigMap хранит данные в открытом виде. Secret использует кодирование Base64.
  • Критическое замечание: Преподаватель подчеркивает, что Base64 — это не шифрование (encryption), а просто кодирование. Любой, у кого есть доступ к неймспейсу, может легко декодировать секрет одной командой.

2. Типы секретов (Secret Types)

В Kubernetes есть несколько стандартных типов:

  1. Opaque (Generic): Обычные данные "ключ-значение".
  2. kubernetes.io/tls: Для хранения сертификатов (нужны два файла: tls.crt и tls.key). Часто используется с Ingress-контроллерами.
  3. kubernetes.io/dockerconfigjson: Для доступа к приватным Docker-регистрам (например, Nexus или Harbor).

3. Работа с секретами в терминале

Преподаватель в видео выполнял следующие действия:

  • Создание секрета из строки (Literal):
kubectl create secret generic secret-1 --from-literal=pass=a1245
  • Просмотр секрета в YAML (где виден Base64):
kubectl get secret secret-1 -o yaml
  • Декодирование секрета (Linux way):

<pre

echo "ЗНАЧЕНИЕ_ИЗ_YAML" | base64 -d
  • Создание секрета из файла:
kubectl create secret generic db-secret --from-file=db.properties

4. Доступ к приватным регистрам (Docker Registry Secret)

Если имидж лежит в приватном Nexus или Harbor, Kubernetes не сможет его скачать без пароля.

  • Решение 1: Создать секрет типа docker-registry и указать его в деплойменте в поле imagePullSecrets.
  • Решение 2 (DevOps way): Настроить логин прямо на уровне Container Runtime (на воркер-нодах), чтобы не прописывать секрет в каждом манифесте.

5. Безопасность и HashiCorp Vault

Так как стандартные секреты K8s не очень безопасны (Base64 легко взломать), профессионалы используют Vault:

  • Sidecar-контейнер (Vault Agent): Рядом с основным приложением в поде запускается агент. Он берет токен, идет в Vault, забирает пароль и подкладывает его приложению.
  • TTL (Time To Live): Токены в Vault живут недолго (например, 15 минут), что гораздо безопаснее статичных паролей.

6. RBAC (Role-Based Access Control)

Это система управления доступом. Она отвечает на вопрос: "Кто и что может делать?".

  • Authentication (Кто ты?): Проверка сертификата или токена.
  • Authorization (Что тебе можно?): Проверка прав (RBAC).
  • Admission Control: Финальная проверка (например, запрет на запуск подов без лимитов ресурсов).

Основные объекты RBAC:

  • Role / ClusterRole: Список правил (например: можно только "геттить" поды).
  • RoleBinding / ClusterRoleBinding: Связка "Роль + Пользователь/Сервис-аккаунт".
Retrieved from "https://wiki.baghirzade.pro/index.php?title=Kubernetes_Secrets,_RBAC_и_Vault&oldid=191"