Керування сертифікатами та параметрами взаємодії із сумісними ЦСК для Сервісу цифрових підписів

Загальний опис

Поточне рішення для Сервісу цифрових підписів передбачає наявність файлів зі Списком сертифікатів сумісних центрів сертифікації ключів (ЦСК) (CACertificates.p7b) та Параметрами взаємодії із сумісними ЦСК (CAs.json) на файловій системі сервісу. На цільовому оточенні ці файли монтуються за допомогою OpenShift секретів, що, втім мають обмеження в розмірі у 1MB. Потрібно розробити рішення, що б дозволило працювати з вищевказаними файлами без обмеження на розмір.

В цьому документі для спрощення Список сертифікатів сумісних центрів сертифікації ключів (ЦСК) = файл CACertificates.p7b, а Параметри взаємодії із сумісними ЦСК = файл CAs.json

Концепти

Список сертифікатів сумісних центрів сертифікації ключів (ЦСК) - файл що містить перелік сертифікатів ЦСК, що вповноважені оформлювати Кваліфікований Електронний Підпис. При перевірці чи накладанні підпису відбувається перевірка, що ключ був випущений Акредитованим Центром Сертифікації Ключів. Список зберігається у форматі PKCS #7 з розширенням .p7b, що зазвичай має назву CACertificates.p7b.
Параметри взаємодії із сумісними ЦСК - файл, що містить додаткову інформацію про ЦСК, таку як Загальне ім’я, та параметри доступу до серверів ЦСК (CMP, TSP та OCSP). Зазвичай має назву CAs.json

Функціональні сценарії

Налаштування Списку сертифікатів сумісних центрів сертифікації ключів (ЦСК) та Параметрів взаємодії із сумісними ЦСК для автентифікації користувачів Адміністратором Платформи
Налаштування Списку сертифікатів сумісних центрів сертифікації ключів (ЦСК) та Параметрів взаємодії із сумісними ЦСК для перевірки підписів Адміністратором Реєстру
Перевірка користувацького електронного підпису
Накладання системного підпису (електронної печатки)

Ролі користувачів

Адміністратор Платформи
Адміністратор Реєстру

Загальні принципи та положення

Файли CACertificates.p7b та CAs.json є публічно доступними по своїй природі і не містять секретної інформації
Сервіс цифрових підписів має можливість використовувати адресу в форматі URL, за якою можна отримати файли CACertificates.p7b та CAs.json
Доступ до файлів CACertificates.p7b та CAs.json по URL не передбачає передачі додаткових параметрів, які не включені в URL конфігурації. За необхідністю додаткові параметри включаються як частина URL
Інтерфейс взаємодії Адміністратора Платформи та Адміністратора Реєстру для налаштування файлів CACertificates.p7b та CAs.json у Веб-інтерфейсі управління Платформою та реєстрами не змінюється
При розгортанні реєстру файли CACertificates.p7b та CAs.json зберігаються в Ceph кошик з публічним доступом до файлу
Для файлів сертифікатів створюється окремий Ceph кошик шляхом додавання ресурсу Object Bucket Claim у Helm Chart Сервісу цифрових підписів
Файли сертифікатів при оновленні перезатираються у Ceph кошику по тому самому ідентифікатору
Імена файлів статичні та посилання на них не змінюються при оновленні
Рішення застосовується як для Сервісу цифрових підписів Підсистеми цифрових підписів, так і для Підсистеми управління користувачами та ролями

Високорівневий дизайн рішення

Figure 1. Діаграма послідовності

Взаємодія пайплану публікації з Ceph

Після створення Object Bucket Claim як частини Helm чарту Сервісу цифрових підписів параметри доступу для нього зберігаються у відповідних Секреті та Конфіг Мапі в тому ж неймспейсі, де і був створений Object Bucket Claim, які будуть мати туж саму назву, що і Object Bucket Claim.

Object Bucket Claim dso-ca-certificates

apiVersion: objectbucket.io/v1alpha1
kind: ObjectBucketClaim
metadata:
  name: dso-ca-certificates
  namespace: registry-ns
spec:
  generateBucketName: dso-certificates
  storageClassName: registry-bucket

Config Map dso-ca-certificates

kind: ConfigMap
apiVersion: v1
metadata:
  name: dso-ca-certificates
  namespace: registry-ns
data:
  BUCKET_HOST: rook-ceph-rgw-mdtuddm.openshift-storage.svc
  BUCKET_NAME: dso-certificates-<<UUID>>
  BUCKET_PORT: '80'
  BUCKET_REGION: ''
  BUCKET_SUBREGION: ''

Secret dso-ca-certificates

kind: Secret
apiVersion: v1
metadata:
  name: dso-ca-certificates
  namespace: registry-ns
data:
  AWS_ACCESS_KEY_ID: <<ACCESS_KEY_ID_VALUE>>
  AWS_SECRET_ACCESS_KEY: <<SECRET_ACCESS_KEY_VALUE>>
type: Opaque

Приклад виконання операції збереження файлу у Ceph

sh '
  AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID \
  AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY \
  AWS_DEFAULT_OUTPUT=json \
  AWS_ENDPOINT_URL=$BUCKET_HOST \
  aws s3 cp dso/config/CACertificates.p7b s3://$BUCKET_NAME/CACertificates.p7b --acl public-read
'

В ході розробки треба переконатись, що виконання команд з Ceph не вплине на глобальну конфігурацію AWS, яка також використовується для іншої функціональності в пайплайні

Ім’я файлів є статичним і має значення CACertificates.p7b та CAs.json відповідно

Після оновлення сертифікатів у Ceph кошику виконується рестарт Деплойменту Сервісу Цифрових Підписів

oc rollout restart deployment/digital-signature-ops

Конфігурація DSO

Конфігурація Сервісу цифрових підписів повинна включати два параметри для отримання файлів сертифікатів (CACertificates.p7b) та конфігурацій доступу (CAs.json) по заданій адресі в форматі URL. Реалізація повинна бути незалежної від природи зберігання файлу і можуть бути використані публічні сервери для отримання вищевказаних файлів.

application.yml. Конфігурація з використанням системного сховища Ceph

ca:
  certificates-url: http://rook-ceph-rgw-mdtuddm.openshift-storage.svc/dso-certificates-3ea4ad25-805b-4a27-8df0-c85066501937/CACertificates.p7b
  config-url: http://rook-ceph-rgw-mdtuddm.openshift-storage.svc/dso-certificates-3ea4ad25-805b-4a27-8df0-c85066501937/CAs.json

application.yml. Конфігурація з використанням публічного сервера сертифікатів

ca:
  certificates-url: https://eu.iit.com.ua/sign-widget/v20200922/Data/CACertificates.p7b?v=30
  config-url: https://eu.iit.com.ua/sign-widget/v20200922/Data/CAs.json?v=30

Варіант з використанням публічного сервера сертифікатів потребує додаткових налаштувань політик мережі

Опційно. Реалізація повинна підтримувати конфігурацію URL для файлів, в тому числі на файловій системі сервісу

application.yml. Конфігурація з використанням файлової системи

ca:
  certificates-url: file:/app/data/CACertificates.p7b
  config-url: file:/app/data/CAs.json

Параметри доступу до Ceph кошика, що включають адресу s3 ендпоінта та назву бакета прокинуті в Деплоймент Сервіс цифрових підписів як змінні оточення

values.yaml

# part of digital-signature-ops Deployment
      env:
        - name: CERT_BUCKET_HOST
          valueFrom:
            configMapKeyRef:
              name: dso-ca-certificates
              key: BUCKET_HOST
        - name: CERT_BUCKET_NAME
          valueFrom:
            configMapKeyRef:
              name: dso-ca-certificates
              key: BUCKET_NAME
# ...

Авторизаційна інформація доступу до кошика не використовується у Сервісі Цифрових Підписів

URL доступу до файлів винесені як параметри Helm values і мають наступні значення, які потенційно можуть бути перевизначені на рівні реєстру (без відповідного інтерфейсу у Веб-інтерфейсі управління Платформою та Реєстрами)

values.yaml

ca:
  certificates-url: http://${CERT_BUCKET_HOST}/${CERT_BUCKET_NAME}/CACertificates.p7b
  config-url: http://${CERT_BUCKET_HOST}/${CERT_BUCKET_NAME}/CAs.json

Параметри прокидаються в Spring застосунок за стандартними в платформі принципом Helm values → Config Map → application.yml → Spring context

Міграція

В рамках міграції потрібно реалізувати видалення ключів CACertificates.p7b та CAs.json у секреті digital-signature-data в пайплайнах розгортання реєстру та платформи

Попередня декомпозиція

[BE] Зміна стратегії отримання файлів сертифікатів та конфігурацій на URL у Сервісі цифрових підписів
[BE] Зміна назв параметрів для кошиків витягів з загальних на більш конкретні (CEPH_BUCKET_HOST → EXCERPT_BUCKET_HOST і інші)
[DEVOPS] Адаптація пайплайну розгортання реєстру для збереження файлів сертифікатів у Ceph кошик (registry dso)
[DEVOPS] Адаптація пайплайну розгортання платформи для збереження файлів сертифікатів у Ceph кошик (user-mng dso)

Поза скоупом

Можливість задавання URL в ручному режимі в Веб-інтерфейсі управління Платформою та реєстрами
Відмова від зберігання файлів сертифікатів у Git репозиторії реєстру
Можливість зберегти файли сертифікатів 1 раз на платформу і задати для всіх реєстрів один і той самий URL

Додаток 1. Розглянуті варіанти в порівнянні

Розгорнути

Варіант	Опис	Плюси	Мінуси	Ціна
Push сертифікатів на файлову систему	Монтуємо замість секрету PV по тому ж шляху. В пайплайні по розгортанню реєстру оновлюємо сертифікати на файловій системі	Дешево. Швидко	Прозорість налаштування. Може бути не очевидно, що для коректної роботи сервісу треба ще щось зробити руками на файловій системі, хоча по факту зараз теж саме можна сказати і про секрети	XS
Pull сертифікатів по публічній урлі	Вказуємо в конфігурації УРЛ по якій скачати сертифікати при старті застосунку. Так само працює віджет	Мінімум змін. Не треба залучати додаткові компоненти. Локальна розробка не відрізняється від запуску на оточенні	Залежність від 3rd party сервісів. Якщо сервер з сертифікатами відпаде, сервіс dso не зможе стартанути. Але якщо він відпаде, віджет так само не буде працювати Додаткові динамічні network policy. Складність використання кастомних ланцюжків. Так потреба виникла тільки тоді, коли виникла помилка з великим розміром секрету	S
Pull сертифікатів по публічній/приватній урлі + управління сертифікатами на платформі	Додаємо можливість адміністратору платформи вказати ланцюжки сертифікатів для платформи. Для них формується урл, який вказується в конфігурації dso	Адресування мінусів з попереднього пункту. Незалежність від 3rd party сервісів. Статичні network policy. Можливість формування кастомних ланцюжків. Можливо розбити на 2 етапи	Максимум змін, додаємо новий функціонал щоб адресувати ризик з нестабільністтю сервера з сертифікатами (спірний момент)	M
Pull сертифікатів з vault/ceph	На оточенні dso при старті забирає сертифікати з вказанням кредів доступу до vault/ceph	Відносно дешеве рішення з точки зору розгортання. Зрозумілий підхід	Ускладнення локального девелопменту. Або тримати декілька стратегій отримання сертифікатів	S
Pull сертифікатів на файлову систему в ініт контейнері	init контейнер на оточенні викачує сертифікати з урли/vault/ceph і скаладає на файлову систему	Жодних змін в DSO. Локально розробка ніяк не змінюється.	Прозорість налаштування. Може бути не очевидно, що для коректної роботи сервісу треба ще щось зробити руками на файловій системі, хоча по факту зараз теж саме можна сказати і про секрети Додаткова розробка init контейнеру	M

Варіант

Опис

Плюси

Мінуси

Ціна

Push сертифікатів на файлову систему

Монтуємо замість секрету PV по тому ж шляху. В пайплайні по розгортанню реєстру оновлюємо сертифікати на файловій системі

Дешево. Швидко

Прозорість налаштування. Може бути не очевидно, що для коректної роботи сервісу треба ще щось зробити руками на файловій системі, хоча по факту зараз теж саме можна сказати і про секрети

Pull сертифікатів по публічній урлі

Вказуємо в конфігурації УРЛ по якій скачати сертифікати при старті застосунку. Так само працює віджет

Мінімум змін. Не треба залучати додаткові компоненти. Локальна розробка не відрізняється від запуску на оточенні

Залежність від 3rd party сервісів. Якщо сервер з сертифікатами відпаде, сервіс dso не зможе стартанути. Але якщо він відпаде, віджет так само не буде працювати
Додаткові динамічні network policy.
Складність використання кастомних ланцюжків. Так потреба виникла тільки тоді, коли виникла помилка з великим розміром секрету

Pull сертифікатів по публічній/приватній урлі + управління сертифікатами на платформі

Додаємо можливість адміністратору платформи вказати ланцюжки сертифікатів для платформи. Для них формується урл, який вказується в конфігурації dso

Адресування мінусів з попереднього пункту. Незалежність від 3rd party сервісів. Статичні network policy. Можливість формування кастомних ланцюжків. Можливо розбити на 2 етапи

Максимум змін, додаємо новий функціонал щоб адресувати ризик з нестабільністтю сервера з сертифікатами (спірний момент)

Pull сертифікатів з vault/ceph

На оточенні dso при старті забирає сертифікати з вказанням кредів доступу до vault/ceph

Відносно дешеве рішення з точки зору розгортання. Зрозумілий підхід

Ускладнення локального девелопменту. Або тримати декілька стратегій отримання сертифікатів

Pull сертифікатів на файлову систему в ініт контейнері

init контейнер на оточенні викачує сертифікати з урли/vault/ceph і скаладає на файлову систему

Жодних змін в DSO. Локально розробка ніяк не змінюється.

Прозорість налаштування. Може бути не очевидно, що для коректної роботи сервісу треба ще щось зробити руками на файловій системі, хоча по факту зараз теж саме можна сказати і про секрети
Додаткова розробка init контейнеру