Kubernetes.Секреты (Secrets) - теория. часть9

Thank you for reading this post, don't forget to subscribe!

В кла­сте­ре Kubernetes объ­ек­ты типа сек­рет (secret) пред­на­зна­че­ны для хра­не­ния кон­фи­ден­ци­аль­ной инфор­ма­ции, такой как паро­ли, OAuth-токе­ны или ssh-ключи.

Пред­став­ле­ние кон­фи­ден­ци­аль­ной инфор­ма­ции в виде сек­ре­та явля­ет­ся более без­опас­ным и гиб­ким, чем добав­ле­ние такой инфор­ма­ции в откры­том виде при опи­са­нии кон­тей­не­ра или сбор­ке docker-образа.

Объ­ек­ты типа сек­рет могут быть созда­ны как поль­зо­ва­те­лем, так и систе­мой. Для исполь­зо­ва­ния сек­ре­та, под (pod) дол­жен на него ссы­лать­ся - чаще все­го как на файл, нахо­дя­щий­ся на при­мон­ти­ро­ван­ном томе. Кро­ме того, kubelet может исполь­зо­вать сек­ре­ты при ска­чи­ва­нии docker-обра­зов из реджистри.

Kubernetes авто­ма­ти­че­ски созда­ет необ­хо­ди­мые ему сек­ре­ты, кото­рые содер­жат учет­ные дан­ные для досту­па к API, и авто­ма­ти­че­ски моди­фи­ци­ру­ет создан­ные поды для исполь­зо­ва­ния это­го секрета.

Объ­ек­ты типа сек­рет могут быть созда­ны с помо­щью коман­ды kubectl create secret. Рас­смот­рим при­мер - допу­стим, для под­клю­че­ния к БД из пода необ­хо­ди­мы логин и пароль, кото­рые нахо­дят­ся в отдель­ных файлах:

echo -n 'admin' > ./username.txt
echo -n 'B7wItYlHeRR1' > ./password.txt

C помо­щью дан­ной коман­ды мож­но пре­об­ра­зо­вать эти два фай­ла в объ­ект типа секрет:

kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
secret "db-user-pass" created

Убе­дить­ся, что сек­рет успеш­но создан мож­но так:

Сто­ит отме­тить, что ни get, ни describe не отоб­ра­зят содер­жи­мое дан­но­го сек­ре­та на экране поль­зо­ва­те­ля - это сде­ла­но из сооб­ра­же­ний безопасности.

Еще один вари­ант созда­ния сек­ре­та - сна­ча­ла опи­сать его в фор­ма­те yaml (или json), и толь­ко после это­го создать сек­рет. Для это­го, каж­дое исполь­зу­е­мое зна­че­ние долж­но быть зако­ди­ро­ва­но в base64:

echo -n 'admin' | base64 YWRtaW4=
echo -n 'B7wItYlHeRR1' | base64 Qjd3SXRZbEhlUlIx

Созда­ем yaml-файл со сле­ду­ю­щим содержимым:

Здесь поле data это map, клю­чи кото­ро­го могут содер­жать бук­вен­но-циф­ро­вые после­до­ва­тель­но­сти и сим­во­лы -_ и ., а зна­че­ния - необ­хо­ди­мые дан­ные, зако­ди­ро­ван­ные в base64.

Теперь мож­но создать сек­рет с исполь­зо­ва­ни­ем коман­ды kubectl create:

kubectl create -f ./secret.yaml
secret "mysecret" created

 

Полу­чим инфор­ма­цию о толь­ко что создан­ном сек­ре­те с помо­щью kubectl get secret (вывод сокращен):

Рас­ко­ди­ро­вать зна­че­ние из сек­ре­та мож­но, напри­мер, так:

echo 'Qjd3SXRZbEhlUlIx' | base64 --decode
B7wItYlHeRR1

Сек­ре­ты могут быть смон­ти­ро­ва­ны как тома дан­ных или опре­де­ле­ны в каче­стве пере­мен­ных окру­же­ния для исполь­зо­ва­ния в подах. Пример:

Если в поде суще­ству­ет несколь­ко кон­тей­не­ров, кото­рые долж­ны исполь­зо­вать дан­ный сек­рет, то сек­цию volumeMounts: сле­ду­ет доба­вить в опи­са­ние каж­до­го из них. Есть воз­мож­ность ука­за­ния кон­крет­но­го пути мон­ти­ро­ва­ния внутрь кон­тей­не­ра зна­че­ния отдель­но­го клю­ча из секрета:

В этом при­ме­ре зна­че­ние username будет доступ­но по пути /etc/foo/my-group/my-username вме­сто /etc/foo/username, а password досту­пен не будет.

При­ме­ча­ние. Мож­но зада­вать пра­ва досту­па к объ­ек­там типа сек­рет (и даже к отдель­ным ключам).

Исполь­зо­ва­ние сек­ре­тов как пере­мен­ных окру­же­ния в опи­са­нии подов выгля­дит так:

После запус­ка пода в кон­тей­не­ре с име­нем mycontainer про­ве­рим пере­мен­ные окружения:

echo $SECRET_USERNAME

admin

echo $SECRET_PASSWORD

B7wItYlHeRR1

Еще один част­ный слу­чай исполь­зо­ва­ния сек­ре­тов - пара­метр imagePullSecrets, кото­рый содер­жит пароль для досту­па к docker-реджи­стри. Подроб­нее о нем мож­но почи­тать здесь