Jak szyfrować ETCD Kubernetes za pomocą OVHcloud KMS

Pokaż jako Markdown

Dowiedz się, jak skonfigurować Kubernetes do szyfrowania magazynu ETCD za pomocą interfejsu KMIP OVHcloud KMS

Wprowadzenie

Ten przewodnik wyjaśnia, jak skonfigurować dostawcę szyfrowania kube-apiserver, umożliwiającego klastrom Kubernetes szyfrowanie i deszyfrowanie danych w spoczynku za pomocą OVHcloud KMS poprzez protokół KMIP.

Wymagania początkowe

W praktyce

Instalacja pliku binarnego

Plik binarny można zainstalować bezpośrednio z pakietów Go.

go install github.com/ovh/okms-k8s-encryption-provider@latest

Możesz go również skompilować ze źródeł.

git clone https://github.com/ovh/okms-k8s-encryption-provider.git
cd okms-k8s-encryption-provider
go build -o okms-k8s-encryption-provider

Konfiguracja OVHcloud KMS (OKMS)

Aby korzystać z OVHcloud KMS jako dostawcy szyfrowania dla Kubernetes, potrzebujesz następujących elementów:

  • Użytkownika OVHcloud oraz uprawnień do zarządzania kluczami KMIP OKMS.
  • Certyfikatu dostępu dla domeny OKMS.
  • Klucza KMIP AES w OKMS.

Tworzenie użytkownika i praw dostępu

Utwórz lokalnego użytkownika IAM z prawami dostępu do domeny.

Jeśli zamiast tego korzystasz z polityk IAM, użytkownik powinien mieć co najmniej następujące prawa do domeny OKMS:

  • okms:kmip:encrypt
  • okms:kmip:decrypt
  • okms:kmip:locate

W przeciwnym razie użytkownik powinien należeć do grupy z rolą ADMIN.

Możesz również utworzyć użytkownika za pomocą CLI OVHcloud:

ovhcloud iam user create --login "etcd-encryption" --group ADMIN --description "A user created for ETCD encryption" --password "xxxxxxxxx" --email "xxxxx@mycompany.com"

Tworzenie certyfikatu dostępu

Utwórz certyfikat dostępu OKMS i połącz go z wcześniej utworzonym użytkownikiem.

Zapisz wygenerowany certyfikat cert.pem oraz klucz prywatny key.pem, ponieważ będą one wymagane do konfiguracji dostawcy szyfrowania.

Tworzenie klucza KMIP AES

Aby utworzyć klucz KMIP AES, możesz użyć CLI OKMS:

Zacznij od pobrania pliku binarnego z najnowszej wersji lub skompilowania go ze źródeł.

Następnie możesz utworzyć klucz za pomocą:

okms-cli kmip create symmetric --alg aes --size 256

Zachowaj Key ID wygenerowanego klucza. W dalszej części przewodnika jako przykład wykorzystamy Key ID 70001308-5674-43fe-93dd-6270ecac0710.

Więcej informacji na temat korzystania z okms-cli znajdziesz w repozytorium GitHub.

Konfiguracja dostawcy szyfrowania

Dostawcę szyfrowania można uruchomić bezpośrednio na hostach kube-apiserver za pomocą następującego polecenia:

./okms-k8s-encryption-provider \
  --client-cert "~/.ovh-kms/cert.pem" \
  --client-key "~/.ovh-kms/key.pem" \
  --kmip-addr "eu-west-par.okms.ovh.net:5696" \
  --kmip-key-id "70001308-5674-43fe-93dd-6270ecac0710"

Dostawca szyfrowania obsługuje następujące opcje:

FlagaOpisDomyślnie
--client-certŚcieżka do pliku certyfikatu klienta używanego do uwierzytelniania w OVHcloud KMS."" (wymagane)
--client-keyŚcieżka do pliku klucza prywatnego powiązanego z certyfikatem klienta."" (wymagane)
--kmip-addrAdres serwera KMIP. Dostępny w . (np. eu-west-rbx.okms.ovh.net:5696)."" (wymagane)
--kmip-key-idIdentyfikator klucza szyfrowania, który ma zostać użyty na serwerze KMIP."" (wymagane)
--sockŚcieżka do gniazda Unix, na którym dostawca będzie nasłuchiwał. Powinno zostać zamontowane wewnątrz apiservera Kubernetes./var/run/okms_etcd_plugin.sock
--timeoutLimit czasu dla operacji serwera gRPC.10s
--debugAktywuj ślady debugowania.false

Konfiguracja Kubernetes

W oparciu o oficjalny przewodnik Kubernetes dotyczący szyfrowania danych za pomocą dostawcy KMS dodaj następujące flagi do kube-apiserver:

  --encryption-provider-config=<path/to>/encryption-config.yaml
  # Opcjonalnie: przeładuj plik, jeśli zostanie zaktualizowany
  --encryption-provider-config-automatic-reload=true

Upewnij się, że katalog zawierający gniazdo Unix, na którym nasłuchuje serwer KMS, został zamontowany w kube-apiserver.

Przykład pliku encryption-config.yaml:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
    - secrets
    providers:
    - kms:
        name: okms-encryption-provider
        endpoint: unix:///var/run/okms_etcd_plugin.sock
        cachesize: 1000
        timeout: 3s
    - identity: {}

Weryfikacja konfiguracji

Utwórz secret za pomocą kubectl create secret generic okms-test-secret -n default --from-literal=mykey=mydata, a następnie sprawdź zawartość tego secret w magazynie ETCD, uruchamiając następujące polecenie:

ETCDCTL_API=3 etcdctl \
    --key /rootfs/etc/kubernetes/pki/kube-apiserver/etcd-client.key \
    --cert  /rootfs/etc/kubernetes/pki/kube-apiserver/etcd-client.crt \
    --cacert /rootfs/etc/kubernetes/pki/kube-apiserver/etcd-ca.crt  \
    --endpoints "https://etcd-a.internal.${CLUSTER}:4001" get /registry/secrets/default/okms-test-secret

Wynik powinien być nieczytelny:

0m`�He.0�cryption-provider:�1x��%�B���#JP��J���*ȝ���΂@\n�96�^��ۦ�~0| *�H��
                    `q�*�J�.P��;&~��o#�O�8m��->8L��0�C3���A7�����~���f�V�ܬ���X��_��`�H#�D��z)+�81��qW��y��`�q��}1<LF, ��N��p����i*�aC#E�߸�s������s��l�?�a
�AźR������.��8H�4�O

Wdrażanie rotacji kluczy

Aby rotować klucz, musisz uruchomić dwóch dostawców szyfrowania, z których każdy nasłuchuje na innym gnieździe Unix.

Poniżej znajduje się przykładowy plik konfiguracji szyfrowania dla wszystkich serwerów API przed rozpoczęciem korzystania z nowego klucza:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
    - secrets
    providers:
    # dostawca używający starego klucza
    - kms:
        name: okms-encryption-provider
        endpoint: unix:///var/run/kmsplugin/socket.sock
        cachesize: 1000
        timeout: 3s
    # dostawca używający nowego klucza
    - kms:
        name: okms-encryption-provider-2
        endpoint: unix:///var/run/kmsplugin/socket2.sock
        cachesize: 1000
        timeout: 3s
    - identity: {}

Po ponownym uruchomieniu wszystkich serwerów API i uzyskaniu przez nie możliwości deszyfrowania za pomocą nowego klucza, przenieś dostawcę z nowym kluczem na górę.

Po ponownym zaszyfrowaniu wszystkich obiektów secret nowym kluczem możesz usunąć starego dostawcę szyfrowania.

Sprawdź również

Dołącz do grona naszych użytkowników.

Dowiedz się, jak korzystać z Kubernetes External Secrets Operator z Secret Manager.

Czy ta strona była pomocna?