🔐 Ротация SSL-сертификатов с помощью OpenShift и Spring Boot |
Главная » Мануал

🔐 Ротация SSL-сертификатов с помощью OpenShift и Spring Boot

Мануал
На чтение 8 мин Опубликовано
Содержание
  1. Обзор
  2. Оператор Service CA в OpenShift
  3. Требования к управлению SSL-сертификатами
  4. Оператор сервисного УЦ
  5. Контроллер подписывающего сертификата сервиса
  6. Оператор OpenShift Service CA в действии
  7. Запуск кластера CodeReady Container (CRC)
  8. Создание приложения Spring Boot с конечной точкой с HTTPS
  9. Развертывание приложения Spring Boot
  10. Проверка
  11. Ручная ротация SSL-сертификата
  12. Заключение

Обзор

OpenShift – это платформа контейнерных приложений, разработанная компанией Red Hat Enterprise.

Она расширяет Kubernetes, добавляя пользовательские компоненты для улучшения работы разработчиков.

Эти компоненты включают в себя встроенную систему пайплайнов CI/CD, реджестри образов контейнеров, сетку сервисов, внутренний сервис центра сертификации (CA) и многое другое.

В этом руководстве мы узнаем об операторе CA сервиса в OpenShift и рассмотрим практический пример, демонстрирующий функциональность оператора CA сервиса.

🦊 Безопасность CI/CD – Как защитить свой пайплайн CI/CD

Оператор Service CA в OpenShift

Чтобы обеспечить шифрование данных при передаче между клиентом и сервером, многие сервисы предпочитают передавать свой трафик по защищенному каналу SSL/TLS.

По сути, оба канала устанавливают защищенный канал связи до передачи данных.

Например, HTTPS – это протокол HTTP, работающий по защищенному каналу.

Чтобы включить защищенный канал SSL/TLS, сервер должен иметь сертификат SSL, а также пары закрытых и открытых ключей.

🔐 В чем разница между файлами .cer и .pfx

Требования к управлению SSL-сертификатами

SSL-сертификаты обычно не хранятся долго в целях безопасности.

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

В обычном кластере Kubernetes управление сертификатом возлагается на администратора.

Многие предпочитают использовать внешний инструмент, например cert-manager, для управления жизненным циклом сертификатов.

В платформе OpenShift есть встроенный оператор сервисного УЦ, который управляет жизненным циклом SSL-сертификатов.

Оператор сервисного УЦ

Оператор сервисного УЦ (Или ЦС) в OpenShift – это компонент, который работает с цифровыми сертификатами.

В частности, оператор создает самоподписанный ЦС при развертывании кластера OpenShift.

Затем он выпускает и вращает цифровые сертификаты для запрашивающих их сервисных ресурсов.

Для поддержки этих функций оператор сервисного ЦС запускает два контроллера:

  • serving cert signer
  • configmap cabundle injector

Давайте вкратце обсудим оба.

Контроллер подписывающего сертификата сервиса

Контроллер подписывающего сертификата – это контроллер для выдачи подписанного сертификата ресурсам сервиса, аннотированным с service.beta.openshift.io/serving-cert-secret-name.

Когда мы развертываем сервисный ресурс с аннотацией service.beta.openshift.io/serving-cert-secret-name=<secret-name>, контроллер генерирует сертификат и соответствующие пары ключей, подписанные сервисным УЦ.

Затем он сохраняет сертификат, tls.crt, и закрытый ключ, tls.key, в объект Secret с тем же именем, что и значение аннотации.

Сгенерированный сертификат действует в течение двух лет до истечения срока его действия.

Кроме того, контроллер автоматически поворачивает сертификат, который он выдает до истечения срока его действия.

Оператор OpenShift Service CA в действии

В этом разделе мы рассмотрим практический пример, демонстрирующий работу оператора Service CA.

Запуск кластера CodeReady Container (CRC)

Существует несколько способов получить доступ к кластеру OpenShift для разработки и тестирования.

Начиная с версии 4.0, мы можем создать локальный кластер OpenShift с помощью CodeReady Container (CRC) или MicroShift.

В данной демонстрации мы используем подход CRC из-за его простоты и почти полного равенства возможностей с полноценным кластером OpenShift.

Для начала, следуя официальному руководству CRC, мы устанавливаем программный комплекс CRC на систему.

Затем мы запускаем кластер с помощью команды crc start:



crc start
....
Started the OpenShift cluster
...
   


Консоль выводит информацию о кластере OpenShift, который мы только что создали.


Следуя инструкциям, мы настраиваем команду oc для указания на новый кластер:




eval $(crc oc-env)
oc login -u developer https://api.crc.testing:6443
   


Затем создадим новый проект в кластере OpenShift с помощью команды oc new-project:




oc create-project ssl-rotate-demonstration
oc projects
You have one project on this server: "ssl-rotate-demonstration".
Using project "ssl-rotate-demonstration" on server "https://api.crc.testing:6443"
   


С новым проектом кластер готов к развертыванию приложений.


Создание приложения Spring Boot с конечной точкой с HTTPS


На данном этапе давайте создадим Docker-образ приложения Spring Boot, которое открывает конечную точку /welcome по протоколу HTTPS.


Мы можем следовать руководству по созданию конечной точки Spring Boot HTTPS за некоторыми исключениями.


Во-первых, нам не нужно генерировать пакет хранилища ключей.


Кроме того, нам нужно указать путь к сертификату и закрытому ключу SSL.


spring.ssl.bundle.pem:
  server:
    keystore:
      certificate: ${CERT_PATH}/tls.crt
      private-key: ${CERT_PATH}/tls.key


Эта конфигурация позволяет указать путь к сертификату и закрытому ключу в базовом пути, CERT_PATH.


Таким образом, мы можем указать этот путь позже в манифесте ресурсов развертывания.


Развертывание приложения Spring Boot


Для развертывания приложений нам необходимы ресурсы службы и развертывания в кластере OpenShift.


Давайте создадим манифест, определяющий ресурс развертывания:




cat deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: ssl-rotate-demonstration-app
spec:
selector:
matchLabels:
ssl-rotate-demonstration-app
template:
metadata:
labels:
app.kubernetes.io/name: ssl-rotate-demonstration-app
spec:
containers:
- image: example/ssl-rotate-demonstration-app:latest
name: ssl-rotate-demonstration-app
ports:
- containerPort: 8443
name: https
env:
- name: CERT_PATH
value: /opt/ssl
volumeMounts:
- mountPath: /opt/ssl
name: server-ssl-bundle
volumes:
- name: server-ssl-bundle
secret:
secretName: server-ssl-bundle
   


В манифесте развертывания мы сопоставляем том server-ssl-bundle с одноименным секретным объектом.


Это секретный объект, который оператор центра обслуживания использует для хранения созданного SSL-сертификата и закрытого ключа.


Затем мы монтируем том по пути /opt/ssl. Наконец, мы завершаем цикл, устанавливая CERT_PATH в /opt/ssl.


Таким образом, приложение должно получить tls.crt и tls.key из секретного объекта server-ssl-bundle.


Затем мы создаем ресурс Service:




cat service.yaml
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/name: ssl-rotate-demonstration-app
annotations:
service.beta.openshift.io/serving-cert-secret-name: server-ssl-bundle
name: ssl-rotate-demonstration-service
spec:
ports:
- name: https
port: 8443
targetPort: 8443
selector:
app.kubernetes.io/name: ssl-rotate-demonstration-app
type: ClusterIP
   


Мы аннотируем ресурс сервиса ключом service.beta.openshift.io/serving-cert-secret-name и значением server-ssl-bundle.


С помощью этой аннотации оператор сервисного УЦ создает секретный пакет server-ssl-bundle, содержащий сгенерированный SSL-сертификат и закрытый ключ.


Для развертывания мы применяем оба манифеста к кластерам OpenShift:




oc apply -f service.yaml
oc apply -f deployment.yaml
   


На этом этапе все должно быть готово. Чтобы подтвердить это, давайте проверим настройку.


Проверка


Чтобы убедиться, что оператор CA действительно создает секретный ресурс, как и ожидалось, мы можем выполнить команду oc describe secret server-ssl-bundle:




oc describe secret server-ssl-bundle
Name:         server-ssl-bundle
Namespace:    ssl-rotate-demonstration
Labels:       <none>
Annotations:  openshift.io/description:
Secret contains a pair signed serving certificate/key that is generated by Service CA operator for service/ssl-rotate-demonstration-servic...
openshift.io/owning-component: service-ca
service.alpha.openshift.io/expiry: 2027-06-01T02:36:37Z
service.beta.openshift.io/expiry: 2027-06-01T02:36:37Z
service.beta.openshift.io/originating-service-name: ssl-rotate-demonstration-service
service.beta.openshift.io/originating-service-uid: 96317ba8-a8af-40f3-9ef9-edb421aa0519
Type:  kubernetes.io/tls
Data
====
tls.crt:  2761 bytes
tls.key:  1679 bytes
   


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


    

  1. Секрет содержит описание, в котором говорится, что он сгенерирован оператором сервисного центра, как и ожидалось.
    2. 

  2. В аннотации service.beta.openshift.io/expiry указана дата истечения срока действия сертификата, которая составляет два года после генерации.
    3. 

  3. В разделе данных мы можем увидеть файл сертификата и закрытый ключ под именами tls.crt и tls.key соответственно.
    4. 



Это говорит о том, что оператор центра обслуживания сгенерировал SSL-сертификат и хранит его в секрете, на который мы можем впоследствии ссылаться в приложении.


Ручная ротация SSL-сертификата


Оператор центра обслуживания должен обеспечить регулярную ротацию SSL-сертификатов до истечения срока их действия.


Однако может возникнуть ситуация, когда нам потребуется принудительная ротация SSL-сертификата. Например, когда закрытый ключ сертификата скомпрометирован, мы можем захотеть обновить все SSL-сертификаты.


Чтобы принудительно повернуть SSL-сертификат, мы можем удалить секретный объект, содержащий SSL-сертификат:




oc delete secret server-ssl-bundle
secret "server-ssl-bundle" deleted
   


Сразу после удаления оператор сервисного центра должен заново создать секрет с новым сертификатом и закрытым ключом:




oc describe secret server-ssl-bundle
Name:         server-ssl-bundle
Namespace:    ssl-rotate-demonstration
Labels:       <none>
Annotations:  openshift.io/description:
Secret contains a pair signed serving certificate/key that is generated by Service CA operator for service/ssl-rotate-demonstration-servic...
openshift.io/owning-component: service-ca
service.alpha.openshift.io/expiry: 2027-06-01T04:15:56Z
service.beta.openshift.io/expiry: 2027-06-01T04:15:56Z
service.beta.openshift.io/originating-service-name: ssl-rotate-demonstration-service
service.beta.openshift.io/originating-service-uid: 96317ba8-a8af-40f3-9ef9-edb421aa0519
Type:  kubernetes.io/tls
Data
====
tls.crt:  2761 bytes
tls.key:  1679 bytes
   


Примечательно, что время истечения срока действия обновлено по сравнению с тем, когда мы впервые описали тот же секретный объект.


Заключение


В этом руководстве мы кратко узнали, что OpenShift строится на основе Kubernetes и предлагает больше компонентов из коробки, которые облегчают процесс разработки.


Затем мы обсудили оператор сервисного центра сертификации и то, как два его контроллера автоматизируют управление сертификатами SSL. Наконец, мы рассмотрели пример развертывания HTTPS-серверного приложения Spring Boot на кластере OpenShift.


см. также:



 
devops DevSecOps OpenShift Spring Boot SSL web security
Пожалуйста, не спамьте и никого не оскорбляйте. Это поле для комментариев, а не спамбокс. Рекламные ссылки не индексируются!
Добавить комментарий