Secrets
Secret — це обʼєкт, який містить невелику кількість конфіденційних даних, таких як пароль, токен або ключ. Така інформація також може бути включена до специфікації Pod або в образ контейнера. Використання Secret означає, що вам не потрібно включати конфіденційні дані у ваш код.
Оскільки Secret можуть бути створені незалежно від Podʼів, які їх використовують, існує менше ризику того, що Secret (і його дані) буде викрито під час процесу створення, перегляду та редагування Podʼів. Kubernetes та програми, які працюють у вашому кластері, також можуть вживати додаткових заходів безпеки щодо Secretʼів, наприклад, уникання запису конфіденційних даних у енергонезалежне сховище.
Secretʼи схожі на ConfigMap, але призначені для зберігання конфіденційних даних.
Увага:
Керовані Kubernetes Secretʼи, стандартно, зберігаються незашифрованими у базі даних API-сервера (etcd). Будь-хто з доступом до API може отримати або змінити Secret, так само як будь-хто з доступом до etcd. Крім того, будь-хто, хто має дозвіл на створення Podʼа у просторі імен, може використовувати цей доступ для читання будь-якого Secretʼу у цьому просторі імен; це включає і непрямий доступ, такий як можливість створення Deployment.
Щоб безпечно використовувати Secretʼи, виконайте принаймні наступні кроки:
- Увімкніть шифрування у стані спокою для Secret.
- Увімкніть або налаштуйте правила RBAC з найменшими правами доступу до Secret.
- Обмежте доступ до Secret для конкретних контейнерів.
- Розгляньте використання зовнішніх постачальників сховища для Secret.
Для отримання додаткових рекомендацій щодо керування та покращення безпеки ваших Secret, ознайомтесь з Належними практиками для Secret Kubernetes.
Дивіться Інформаційна безпека для Secret для отримання додаткових відомостей.
Застосування Secretʼів
Ви можете використовувати Secrets для таких цілей:
- Встановлення змінних оточення для контейнера.
- Надання облікових даних, таких як SSH-ключі або паролі, Podʼам.
- Дозвіл kubelet отримувати образи контейнера з приватних реєстрів.
Панель управління Kubernetes також використовує Secretʼи; наприклад, Secret токену реєстрації вузлів — це механізм, що допомагає автоматизувати реєстрацію вузлів.
Сценарій використання: dotfiles у томі Secret
Ви можете зробити ваші дані "прихованими", визначивши ключ, який починається з крапки. Цей ключ являє собою dotfile або "прихований" файл. Наприклад, коли наступний Secret підключається до тому secret-volume
, том буде містити один файл, з назвою .secret-file
, і контейнер dotfile-test-container
матиме цей файл присутнім у шляху /etc/secret-volume/.secret-file
.
Примітка:
Файли, які починаються з крапок, приховані від виводуls -l
; для того, щоб побачити їх під час перегляду вмісту каталогу використовуйте ls -la
.apiVersion: v1
kind: Secret
metadata:
name: dotfile-secret
data:
.secret-file: dmFsdWUtMg0KDQo=
---
apiVersion: v1
kind: Pod
metadata:
name: secret-dotfiles-pod
spec:
volumes:
- name: secret-volume
secret:
secretName: dotfile-secret
containers:
- name: dotfile-test-container
image: registry.k8s.io/busybox
command:
- ls
- "-l"
- "/etc/secret-volume"
volumeMounts:
- name: secret-volume
readOnly: true
mountPath: "/etc/secret-volume"
Сценарій використання: Secret видимий для одного контейнера в Pod
Припустимо, що у вас є програма, яка потребує обробки HTTP-запитів, виконання складної бізнес-логіки та підписування деяких повідомлень HMAC. Оскільки у неї складна логіка застосунків, може бути непоміченою вразливість на віддалене читання файлів з сервера, що може дати доступ до приватного ключа зловмиснику.
Це можна розділити на два процеси у двох контейнерах: контейнер інтерфейсу, який обробляє взаємодію з користувачем та бізнес-логіку, але не може бачити приватний ключ; і контейнер що перевіряє підписи, який може бачити приватний ключ, та відповідає на прості запити на підпис від фронтенду (наприклад, через мережу localhost).
З цим розділеним підходом зловмиснику зараз потрібно обманути сервер застосунків, щоб зробити щось досить довільне, що може бути складніше, ніж змусити його прочитати файл.
Альтернативи Secretʼам
Замість використання Secret для захисту конфіденційних даних, ви можете вибрати з альтернатив.
Ось деякі з варіантів:
- Якщо ваш хмарно-орієнтований компонент потребує автентифікації від іншого застосунку, який, ви знаєте, працює в межах того ж кластера Kubernetes, ви можете використовувати ServiceAccount та його токени, щоб ідентифікувати вашого клієнта.
- Існують сторонні інструменти, які ви можете запускати, як в межах, так і поза вашим кластером, які керують чутливими даними. Наприклад, Service, до якого Podʼи мають доступ через HTTPS, який використовує Secret, якщо клієнт правильно автентифікується (наприклад, з токеном ServiceAccount).
- Для автентифікації ви можете реалізувати спеціальний підписувач для сертифікатів X.509, і використовувати CertificateSigningRequests, щоб дозволити цьому спеціальному підписувачу видавати сертифікати Podʼам, які їх потребують.
- Ви можете використовувати втулок пристрою, щоб використовувати апаратне забезпечення шифрування, яке локалізоване на вузлі, для певного Podʼа. Наприклад, ви можете розмістити довірені Podʼи на вузлах, які надають Trusted Platform Module.
Ви також можете комбінувати два або більше з цих варіантів, включаючи варіант використання Secret самостійно.
Наприклад: реалізуйте (або розгорніть) оператор, що отримує тимчасові токени сеансів від зовнішнього Service, а потім створює Secretʼи на основі цих тимчасових токенів. Podʼи, що працюють у вашому кластері, можуть використовувати токени сеансів, а оператор забезпечує їхню дійсність. Це розподілення означає, що ви можете запускати Podʼи, які не знають точних механізмів створення та оновлення цих токенів сеансів.
Типи Secret
При створенні Secret ви можете вказати його тип, використовуючи поле type
ресурсу Secret, або певні еквівалентні прапорці командного рядка kubectl
(якщо вони доступні). Тип Secret використовується для сприяння програмному обробленню даних Secret.
Kubernetes надає кілька вбудованих типів для деяких типових сценаріїв використання. Ці типи відрізняються за умовами перевірки та обмеженнями, які Kubernetes накладає на них.
Вбудований Тип | Використання |
---|---|
Opaque | довільні користувацькі дані |
kubernetes.io/service-account-token | токен ServiceAccount |
kubernetes.io/dockercfg | серіалізований файл ~/.dockercfg |
kubernetes.io/dockerconfigjson | серіалізований файл ~/.docker/config.json |
kubernetes.io/basic-auth | облікові дані для базової автентифікації |
kubernetes.io/ssh-auth | облікові дані для SSH автентифікації |
kubernetes.io/tls | дані для TLS клієнта або сервера |
bootstrap.kubernetes.io/token | дані bootstrap token |
Ви можете визначити та використовувати власний тип Secret, присвоївши непорожній рядок як значення type
обʼєкту Secret (порожній рядок розглядається як тип Opaque
).
Kubernetes не накладає жодних обмежень на назву типу. Однак, якщо ви використовуєте один з вбудованих типів, ви повинні задовольнити всі вимоги, визначені для цього типу.
Якщо ви визначаєте тип Secret, призначений для загального використання, дотримуйтесь домовленостей та структуруйте тип Secret так, щоб він мав ваш домен перед назвою, розділений знаком /
. Наприклад: cloud-hosting.example.net/cloud-api-credentials
.
Opaque Secrets
Opaque
— це стандартний тип Secret, якщо ви не вказуєте явно тип у маніфесті Secret. При створенні Secret за допомогою kubectl
вам потрібно використовувати команду generic
, щоб вказати тип Secret Opaque
. Наприклад, наступна команда створює порожній Secret типу Opaque
:
kubectl create secret generic empty-secret
kubectl get secret empty-secret
Вивід виглядає наступним чином:
NAME TYPE DATA AGE
empty-secret Opaque 0 2m6s
У стовпчику DATA
показується кількість елементів даних, збережених у Secret. У цьому випадку 0
означає, що ви створили порожній Secret.
Secret токенів ServiceAccount
Тип Secret kubernetes.io/service-account-token
використовується для зберігання
токену, який ідентифікує ServiceAccount. Це старий механізм, який забезпечує довгострокові облікові дані ServiceAccount для Podʼів.
У Kubernetes v1.22 та пізніших рекомендований підхід полягає в тому, щоб отримати короткостроковий, токен ServiceAccount який автоматично змінюється за допомогою API [TokenRequest
](/docs/reference/kubernetes-api/authentication-resources/ token-request-v1/) замість цього. Ви можете отримати ці короткострокові токени, використовуючи наступні методи:
- Викликайте API
TokenRequest
або використовуйте клієнт API, такий якkubectl
. Наприклад, ви можете використовувати командуkubectl create token
. - Запитуйте монтований токен в томі projected у вашому маніфесті Podʼа. Kubernetes створює токен і монтує його в Pod. Токен автоматично анулюється, коли Pod, в якому він монтується, видаляється. Докладні відомості див. в розділі Запуск Podʼа за допомогою токена ServiceAccount.
Примітка:
Ви повинні створювати Secret токена ServiceAccount лише в тому випадку, якщо ви не можете використовувати APITokenRequest
для отримання токена, і вам прийнятно з погляду безпеки зберігання постійного токена доступу у читабельному обʼєкті API. Для інструкцій див. Створення довгострокового API-токена для ServiceAccount вручну.При використанні цього типу Secret вам потрібно переконатися, що анотація kubernetes.io/service-account.name
встановлена на наявне імʼя ServiceAccount. Якщо ви створюєте як Secret, так і обʼєкти ServiceAccount, ви повинні спочатку створити обʼєкт ServiceAccount.
Після створення Secret контролер Kubernetes заповнює деякі інші поля, такі як анотація kubernetes.io/service-account.uid
, та ключ token
в полі data
, який заповнюється токеном автентифікації.
У наступному прикладі конфігурації оголошується Secret токена ServiceAccount:
apiVersion: v1
kind: Secret
metadata:
name: secret-sa-sample
annotations:
kubernetes.io/service-account.name: "sa-name"
type: kubernetes.io/service-account-token
data:
extra: YmFyCg==
Після створення Secret дочекайтеся, коли Kubernetes заповнить ключ token
в полі data
.
Для отримання додаткової інформації про роботу ServiceAccounts перегляньте документацію по ServiceAccount. Ви також можете перевірити поле automountServiceAccountToken
та поле serviceAccountName
у Pod
для отримання інформації про посилання на облікові дані ServiceAccount з Podʼів.
Secret конфігурації Docker
Якщо ви створюєте Secret для зберігання облікових даних для доступу до реєстру образів контейнерів, ви повинні використовувати одне з наступних значень type
для цього Secret:
kubernetes.io/dockercfg
: збереже серіалізований~/.dockercfg
, який є старим форматом налаштування командного рядка Docker. У поліdata
Secret міститься ключ.dockercfg
, значення якого — це вміст файлу~/.dockercfg
, закодованого у форматі base64.kubernetes.io/dockerconfigjson
: збереже серіалізований JSON, який слідує тим же правилам формату, що й файл~/.docker/config.json
, який є новим форматом для~/.dockercfg
. У поліdata
Secret має міститися ключ.dockerconfigjson
, значення якого – це вміст файлу~/.docker/config.json
, закодованого у форматі base64.
Нижче наведено приклад для Secret типу kubernetes.io/dockercfg
:
apiVersion: v1
kind: Secret
metadata:
name: secret-dockercfg
type: kubernetes.io/dockercfg
data:
.dockercfg: |
eyJhdXRocyI6eyJodHRwczovL2V4YW1wbGUvdjEvIjp7ImF1dGgiOiJvcGVuc2VzYW1lIn19fQo=
Примітка:
Якщо ви не хочете виконувати кодування у формат base64, ви можете вибрати використання поляstringData
замість цього.При створенні Secret конфігурації Docker за допомогою маніфесту, API сервер перевіряє, чи існує відповідний ключ у полі data
, і перевіряє, чи надане значення можна розпізнати як дійсний JSON. API сервер не перевіряє, чи є цей JSON фактично файлом конфігурації Docker.
Ви також можете використовувати kubectl
для створення Secret для доступу до реєстру контейнерів, наприклад, коли у вас немає файлу конфігурації Docker:
kubectl create secret docker-registry secret-tiger-docker \
--docker-email=tiger@acme.example \
--docker-username=tiger \
--docker-password=pass1234 \
--docker-server=my-registry.example:5000
Ця команда створює Secret типу kubernetes.io/dockerconfigjson
.
Отримайте поле .data.dockerconfigjson
з цього нового Secret та розкодуйте дані:
kubectl get secret secret-tiger-docker -o jsonpath='{.data.*}' | base64 -d
Вихід еквівалентний наступному JSON-документу (який також є дійсним файлом конфігурації Docker):
{
"auths": {
"my-registry.example:5000": {
"username": "tiger",
"password": "pass1234",
"email": "tiger@acme.example",
"auth": "dGlnZXI6cGFzczEyMzQ="
}
}
}
Увага:
Значення auth
закодовано у формат base64; воно зашифроване, але не є Secretним. Будь-хто, хто може прочитати цей Secret, може дізнатися токен доступу до реєстру.
Рекомендується використовувати постачальників облікових записів для динамічного і безпечного надання Secretʼів на запит.
Secret базової автентифікації
Тип kubernetes.io/basic-auth
наданий для зберігання облікових даних, необхідних для базової автентифікації. При використанні цього типу Secret, поле data
Secret повинно містити один з двох наступних ключів:
username
: імʼя користувача для автентифікаціїpassword
: пароль або токен для автентифікації
Обидва значення для цих ключів закодовані у формат base64. Ви також можете надати чіткий текст, використовуючи поле stringData
у маніфесті Secret.
Наступний маніфест є прикладом Secret для базової автентифікації:
apiVersion: v1
kind: Secret
metadata:
name: secret-basic-auth
type: kubernetes.io/basic-auth
stringData:
username: admin # обовʼязкове поле для kubernetes.io/basic-auth
password: t0p-Secret # обовʼязкове поле для kubernetes.io/basic-auth
Примітка:
ПолеstringData
для Secret не дуже підходить для застосування на боці сервера.Тип Secret для базової автентифікації наданий лише для зручності. Ви можете створити тип Opaque
для облікових даних, які використовуються для базової автентифікації. Однак використання визначеного та публічного типу Secret (kubernetes.io/basic-auth
) допомагає іншим людям зрозуміти призначення вашого Secret та встановлює домовленості для очікуваних назв ключів.
Secret для автентифікації SSH
Вбудований тип kubernetes.io/ssh-auth
наданий для зберігання даних, що використовуються в автентифікації SSH. При використанні цього типу Secret, вам потрібно вказати пару ключ-значення ssh-privatekey
в полі data
(або stringData
) як SSH-автентифікаційні дані для використання.
Наступний маніфест є прикладом Secret, який використовується для автентифікації SSH з використанням пари публічного/приватного ключів:
apiVersion: v1
kind: Secret
metadata:
name: secret-ssh-auth
type: kubernetes.io/ssh-auth
data:
# в цьомум прикладі поле data скорочене
ssh-privatekey: |
UG91cmluZzYlRW1vdGljb24lU2N1YmE=
Тип Secret для автентифікації SSH наданий лише для зручності. Ви можете створити тип Opaque
для облікових даних, які використовуються для автентифікації SSH. Однак використання визначеного та публічного типу Secret (kubernetes.io/ssh-auth
) допомагає іншим людям зрозуміти призначення вашого Secret та встановлює домовленості для очікуваних назв ключів. API Kubernetes перевіряє, чи встановлені необхідні ключі для Secret цього типу.
Увага:
Приватні ключі SSH не встановлюють довіру між клієнтом SSH та сервером хосту самі по собі. Для зменшення ризику атак "man-in-the-middle" потрібен додатковий спосіб встановлення довіри, наприклад, файлknown_hosts
, доданий до ConfigMap.TLS Secrets
Тип Secret kubernetes.io/tls
призначений для зберігання сертифіката та його повʼязаного ключа, які зазвичай використовуються для TLS.
Одним з поширених використань TLS Secret є налаштування шифрування під час передачі для
Ingress, але ви також можете використовувати його з іншими ресурсами або безпосередньо у вашій роботі. При використанні цього типу Secret ключі tls.key
та tls.crt
повинні бути надані в полі data
(або stringData
) конфігурації Secret, хоча сервер API фактично не перевіряє значення кожного ключа.
Як альтернативу використанню stringData
, ви можете використовувати поле data
для надання сертифіката та приватного ключа у вигляді base64-кодованого тексту. Докладніше див. Обмеження для назв і даних Secret.
Наступний YAML містить приклад конфігурації TLS Secret:
apiVersion: v1
kind: Secret
metadata:
name: secret-tls
type: kubernetes.io/tls
data:
# значення закодовані в форматі base64, що приховує їх, але НЕ забезпечує
# жодного рівня конфіденційності
tls.crt: |
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNVakNDQWJzQ0FnMytNQTBHQ1NxR1NJYjNE
UUVCQlFVQU1JR2JNUXN3Q1FZRFZRUUdFd0pLVURFT01Bd0cKQTFVRUNCTUZWRzlyZVc4eEVEQU9C
Z05WQkFjVEIwTm9kVzh0YTNVeEVUQVBCZ05WQkFvVENFWnlZVzVyTkVSRQpNUmd3RmdZRFZRUUxF
dzlYWldKRFpYSjBJRk4xY0hCdmNuUXhHREFXQmdOVkJBTVREMFp5WVc1ck5FUkVJRmRsCllpQkRR
VEVqTUNFR0NTcUdTSWIzRFFFSkFSWVVjM1Z3Y0c5eWRFQm1jbUZ1YXpSa1pDNWpiMjB3SGhjTk1U
TXcKTVRFeE1EUTFNVE01V2hjTk1UZ3dNVEV3TURRMU1UTTVXakJMTVFzd0NRWURWUVFHREFKS1VE
RVBNQTBHQTFVRQpDQXdHWEZSdmEzbHZNUkV3RHdZRFZRUUtEQWhHY21GdWF6UkVSREVZTUJZR0Ex
VUVBd3dQZDNkM0xtVjRZVzF3CmJHVXVZMjl0TUlHYU1BMEdDU3FHU0liM0RRRUJBUVVBQTRHSUFE
Q0JoQUo5WThFaUhmeHhNL25PbjJTbkkxWHgKRHdPdEJEVDFKRjBReTliMVlKanV2YjdjaTEwZjVN
Vm1UQllqMUZTVWZNOU1vejJDVVFZdW4yRFljV29IcFA4ZQpqSG1BUFVrNVd5cDJRN1ArMjh1bklI
QkphVGZlQ09PekZSUFY2MEdTWWUzNmFScG04L3dVVm16eGFLOGtCOWVaCmhPN3F1TjdtSWQxL2pW
cTNKODhDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUVVGQUFPQmdRQU1meTQzeE15OHh3QTUKVjF2T2NS
OEtyNWNaSXdtbFhCUU8xeFEzazlxSGtyNFlUY1JxTVQ5WjVKTm1rWHYxK2VSaGcwTi9WMW5NUTRZ
RgpnWXcxbnlESnBnOTduZUV4VzQyeXVlMFlHSDYyV1hYUUhyOVNVREgrRlowVnQvRGZsdklVTWRj
UUFEZjM4aU9zCjlQbG1kb3YrcE0vNCs5a1h5aDhSUEkzZXZ6OS9NQT09Ci0tLS0tRU5EIENFUlRJ
RklDQVRFLS0tLS0K
# У цьому прикладі, дані не є справжнім приватним ключем в форматі PEM
tls.key: |
RXhhbXBsZSBkYXRhIGZvciB0aGUgVExTIGNydCBmaWVsZA==
Тип TLS Secret наданий лише для зручності. Ви можете створити тип Opaque
для облікових даних, які використовуються для TLS-автентифікації. Однак використання визначеного та публічного типу Secret (kubernetes.io/tls
) допомагає забезпечити однорідність формату Secret у вашому проєкті. Сервер API перевіряє, чи встановлені необхідні ключі для Secret цього типу.
Для створення TLS Secret за допомогою kubectl
використовуйте підкоманду tls
:
kubectl create secret tls my-tls-secret \
--cert=path/to/cert/file \
--key=path/to/key/file
Пара публічного/приватного ключа повинна бути створена заздалегідь. Публічний ключ сертифіката для --cert
повинен бути закодований у .PEM форматі і повинен відповідати наданому приватному ключу для --key
.
Secret bootstrap-токенів
Тип Secret bootstrap.kubernetes.io/token
призначений для токенів, що використовуються під час процесу ініціалізації вузла. Він зберігає токени, які використовуються для підпису відомих ConfigMaps.
Secret токена ініціалізації зазвичай створюється в просторі імен kube-system
і називається у формі bootstrap-token-<token-id>
, де <token-id>
— це 6-символьний
рядок ідентифікатора токена.
Як Kubernetes маніфест, Secret токена ініціалізації може виглядати наступним чином:
apiVersion: v1
kind: Secret
metadata:
name: bootstrap-token-5emitj
namespace: kube-system
type: bootstrap.kubernetes.io/token
data:
auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4=
expiration: MjAyMC0wOS0xM1QwNDozOToxMFo=
token-id: NWVtaXRq
token-secret: a3E0Z2lodnN6emduMXAwcg==
usage-bootstrap-authentication: dHJ1ZQ==
usage-bootstrap-signing: dHJ1ZQ==
У Secret токена ініціалізації вказані наступні ключі в data
:
token-id
: Випадковий рядок з 6 символів як ідентифікатор токена. Обовʼязковий.token-secret
: Випадковий рядок з 16 символів як сам Secret токена. Обовʼязковий.description
: Рядок, що призначений для користувачів, що описує, для чого використовується токен. Необовʼязковий.expiration
: Абсолютний час UTC, відповідно до RFC3339, що вказує, коли дія токена має бути закінчена. Необовʼязковий.usage-bootstrap-<usage>
: Логічний прапорець, який вказує додаткове використання для токена ініціалізації.auth-extra-groups
: Список імен груп, розділених комами, які будуть автентифікуватися як додатково до групиsystem:bootstrappers
.
Ви також можете надати значення в полі stringData
Secret без їх base64 кодування:
apiVersion: v1
kind: Secret
metadata:
# Зверніть увагу, як названий Secret
name: bootstrap-token-5emitj
# Зазвичай, Secret з bootstrap token знаходиться в просторі імен kube-system
namespace: kube-system
type: bootstrap.kubernetes.io/token
stringData:
auth-extra-groups: "system:bootstrappers:kubeadm:default-node-token"
expiration: "2020-09-13T04:39:10Z"
# Цей ідентифікатор токена використовується в назві
token-id: "5emitj"
token-secret: "kq4gihvszzgn1p0r"
# Цей токен може бути використаний для автентифікації
usage-bootstrap-authentication: "true"
# і він може бути використаний для підпису
usage-bootstrap-signing: "true"
Примітка:
ПолеstringData
для Secret погано працює на боці сервера.Робота з Secret
Створення Secret
Є кілька способів створення Secret:
Обмеження щодо імен і даних Secret
Імʼя обʼєкта Secret повинно бути дійсним імʼям DNS-піддомену.
Ви можете вказати поля data
і/або stringData
при створенні файлу конфігурації для Secret. Поля data
і stringData
є необовʼязковими. Значення для всіх ключів у полі data
повинні бути base64-кодованими рядками. Якщо перетворення у рядок base64 не є бажаним, ви можете вибрати поле stringData
, яке приймає довільні рядки як значення.
Ключі data
і stringData
повинні складатися з буквено-цифрових символів, -
, _
або .
. Усі пари ключ-значення в полі stringData
внутрішньо обʼєднуються в поле data
. Якщо ключ зустрічається як у полі data
, так і у полі stringData
, значення, вказане у полі stringData
, має пріоритет.
Обмеження розміру
Індивідуальні Secretʼи обмежені розміром 1 МБ. Це зроблено для того, щоб уникнути створення дуже великих Secret, які можуть вичерпати памʼять API-сервера та kubelet. Однак створення багатьох менших Secret також може вичерпати памʼять. Ви можете використовувати квоту ресурсів для обмеження кількості Secret (або інших ресурсів) в просторі імен.
Редагування Secret
Ви можете редагувати наявний Secret, якщо він не є незмінним. Для редагування Secret скористайтеся одним із наступних методів:
Ви також можете редагувати дані у Secret за допомогою інструменту Kustomize. Проте цей метод створює новий обʼєкт Secret
з відредагованими даними.
Залежно від того, як ви створили Secret, а також від того, як Secret використовується в ваших Podʼах, оновлення існуючих обʼєктів Secret
автоматично поширюються на Podʼи, які використовують дані. Для отримання додаткової інформації звертайтеся до розділу Використання Secret як файлів у Podʼі.
Використання Secret
Secret можна монтувати як томи даних або використовувати як змінні оточення для використання контейнером в Podʼі. Secret також можна використовувати іншими частинами системи, не надаючи прямого доступу до Podʼа. Наприклад, Secret можуть містити автентифікаційні дані, які інші частини системи повинні використовувати для взаємодії зовнішніми системами від вашого імені.
Джерела томів Secret перевіряються на наявність для того, щоб переконатися, що вказано посилання на обʼєкт дійсно вказує на обʼєкт типу Secret. Тому Secret повинен бути створений перед будь-якими Podʼами, які залежать від нього.
Якщо Secret не може бути отриманий (можливо, через те, що він не існує, або через тимчасову відсутність зʼєднання з сервером API), kubelet періодично повторює спробу запуску цього Podʼа. Крім того, kubelet також реєструє подію для цього Podʼа, включаючи деталі проблеми отримання Secret.
Необовʼязкові Secret
Коли ви посилаєтеся на Secret у Podʼі, ви можете позначити Secret як необовʼязковий, як у наступному прикладі. Якщо необовʼязковий Secret не існує, Kubernetes ігнорує його.
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: redis
volumeMounts:
- name: foo
mountPath: "/etc/foo"
readOnly: true
volumes:
- name: foo
secret:
secretName: mysecret
optional: true
Типово Secret є обовʼязковими. Жоден з контейнерів Podʼа не розпочне роботу, доки всі обовʼязкові Secret не будуть доступні.
Якщо Pod посилається на певний ключ у необовʼязковому Secret і цей Secret існує, але відсутній зазначений ключ, Pod не запускається під час старту.
Використання Secret у вигляді файлів у Pod
Якщо ви хочете отримати доступ до даних з Secret у Podʼі, один із способів зробити це — це дозволити Kubernetes робити значення цього Secret доступним як файл у файловій системі одного або декількох контейнерів Podʼа.
Щоб це зробити, дивіться Створення Podʼа, який має доступ до секретних даних через Volume.
Коли том містить дані з Secret, а цей Secret оновлюється, Kubernetes відстежує це і оновлює дані в томі, використовуючи підхід з подальшою згодою.
Примітка:
Контейнер, який використовує Secret як том subPath, не отримує автоматичних оновлень Secret.Kubelet зберігає кеш поточних ключів та значень для Secret, які використовуються у томах для Podʼів на цьому вузлі. Ви можете налаштувати спосіб, яким kubelet виявляє зміни від кешованих значень. Поле configMapAndSecretChangeDetectionStrategy
в конфігурації kubelet контролює стратегію, яку використовує kubelet. Стандартною стратегією є Watch
.
Оновлення Secret можуть бути передані за допомогою механізму спостереження за API (стандартно), на основі кешу з визначеним часом життя або отримані зі API-сервера кластера в кожнному циклі синхронізації kubelet.
Як результат, загальна затримка від моменту оновлення Secret до моменту, коли нові ключі зʼявляються в Podʼі, може бути такою ж тривалою, як період синхронізації kubelet + затримка розповсюдження кешу, де затримка розповсюдження кешу залежить від обраного типу кешу (перший у списку це затримка розповсюдження спостереження, налаштований TTL кешу або нуль для прямого отримання).
Використання Secret як змінних оточення
Для використання Secret в змінних оточення в Podʼі:
- Для кожного контейнера у вашому описі Podʼа додайте змінну оточення для кожного ключа Secret, який ви хочете використовувати, у поле
env[].valueFrom.secretKeyRef
. - Змініть свій образ і/або командний рядок так, щоб програма шукала значення у вказаних змінних оточення.
Для отримання інструкцій дивіться Визначення змінних оточення контейнера за допомогою даних Secret.
Важливо зауважити, що діапазон символів, дозволених для назв змінних середовища в Podʼах, обмежений. Якщо будь-які ключі не відповідають правилам, ці ключі не будуть доступні вашому контейнеру, хоча Pod може бути запущений.
Використання Secret для витягування образів контейнерів
Якщо ви хочете отримувати образи контейнерів з приватного репозиторію, вам потрібен спосіб автентифікації для kubelet на кожному вузлі для доступу до цього репозиторію. Ви можете налаштувати Secret для витягування образів для досягнення цієї мети. Ці Secret налаштовані на рівні Pod.
Використання imagePullSecrets
Поле imagePullSecrets
є списком посилань на Secret в тому ж просторі імен. Ви можете використовувати imagePullSecrets
, щоб передати Secret, який містить пароль Docker (або іншого) репозиторію образів, в kubelet. Kubelet використовує цю інформацію для витягування приватного образу від імені вашого Podʼа. Для отримання додаткової інформації про поле imagePullSecrets
, дивіться PodSpec API.
Ручне вказання imagePullSecret
Ви можете дізнатися, як вказати imagePullSecrets
, переглянувши документацію про образи контейнерів.
Організація автоматичного приєднання imagePullSecrets
Ви можете вручну створити imagePullSecrets
та посилатися на них з ServiceAccount. Будь-які Podʼи, створені з цим ServiceAccount або створені з цим ServiceAccount, отримають своє поле imagePullSecrets
, встановлене на відповідне для сервісного облікового запису. Дивіться Додавання ImagePullSecrets до Service Account для детального пояснення цього процесу.
Використання Secret зі статичними Podʼами
Ви не можете використовувати ConfigMaps або Secrets зі статичними Podʼами.
Незмінні Secret
Kubernetes v1.21 [stable]
Kubernetes дозволяє вам позначати певні Secret (і ConfigMaps) як незмінні. Запобігання змінам даних існуючого Secret має наступні переваги:
- захищає вас від випадкових (або небажаних) оновлень, які можуть призвести до відмов застосунків
- (для кластерів, що широко використовують Secret — щонайменше десятки тисяч унікальних монтувань Secret у Podʼи), перехід до незмінних Secret покращує продуктивність вашого кластера шляхом значного зменшення навантаження на kube-apiserver. kubeletʼу не потрібно підтримувати [watch] за будь-якими Secret, які позначені як незмінні.
Позначення Secret як незмінного
Ви можете створити незмінний Secret, встановивши поле immutable
в true
. Наприклад,
apiVersion: v1
kind: Secret
metadata: ...
data: ...
immutable: true
Ви також можете оновити будь-який наявний змінний Secret, щоб зробити його незмінним.
Примітка:
Як тільки Secret або ConfigMap позначений як незмінний, цю зміну неможливо скасувати чи змінити зміст поляdata
. Ви можете тільки видалити і знову створити Secret. Наявні Podʼи зберігають точку монтування для видаленого Secret — рекомендується перестворити ці Podʼи.Інформаційна безпека для Secret
Хоча ConfigMap і Secret працюють схоже, Kubernetes застосовує додаткові заходи захисту для обʼєктів Secret.
Secret часто містять значення, які охоплюють широкий спектр важливостей, багато з яких можуть викликати ескалації всередині Kubernetes (наприклад, токени облікових записів служби) та зовнішніх систем. Навіть якщо окремий застосунок може мати на меті використання Secret, з якими він очікує взаємодіяти, інші застосунки в тому ж просторі імен можуть зробити ці припущення недійсними.
Secret буде відправлений на вузол тільки у випадку, якщо на цьому вузлі є Pod, якому він потрібен. Для монтування Secret Podʼи kubelet зберігає копію даних у tmpfs
, щоб конфіденційні дані не записувалися у носії з довгостроковим зберіганням. Коли Pod, який залежить від Secret, видаляється, kubelet видаляє свою локальну копію конфіденційних даних з Secret.
У Podʼі може бути кілька контейнерів. Типово контейнери, які ви визначаєте, мають доступ тільки до службового стандартного облікового запису та повʼязаного з ним Secret. Вам потрібно явно визначити змінні середовища або відобразити том у контейнері, щоб надати доступ до будь-якого іншого Secret.
Може бути Secret для кількох Podʼів на тому ж вузлі. Проте тільки Secretʼи, які запитує Pod, можливо бачити всередині його контейнерів. Таким чином, один Pod не має доступу до Secretʼів іншого Podʼа.
Налаштування доступу за принципом найменшого дозволу до Secret
Щоб посилити заходи безпеки навколо Secrets, використовуйте окремі простори імен для ізоляції доступу до змонтованих секретів.
Попередження:
Будь-які контейнери, які працюють з параметромprivileged: true
на вузлі, можуть отримати доступ до всіх Secret, що використовуються на цьому вузлі.Що далі
- Для настанов щодо керування та покращення безпеки ваших Secret перегляньте Рекомендаціх щодо Secret в Kubernetes.
- Дізнайтеся, як керувати Secret за допомогою
kubectl
- Дізнайтеся, як керувати Secret за допомогою конфігураційного файлу
- Дізнайтеся, як керувати Secret за допомогою kustomize
- Прочитайте довідник API для
Secret
.