Beranda>Terkait pemrograman>Kode sumber lainnya
Unduh

"Rahasia Tersegel" untuk Kubernetes

Membangun Status

Masalah: "Saya dapat mengelola semua konfigurasi K8 saya di git, kecuali Rahasia."

Solusi: Enkripsikan Rahasia Anda ke dalam SealedSecret, yang aman untuk disimpan - bahkan di dalam repositori publik. SealedSecret hanya dapat didekripsi oleh pengontrol yang berjalan di cluster target dan tidak ada orang lain (bahkan pembuat aslinya) yang dapat memperoleh Rahasia asli dari SealedSecret.

  • Ringkasan

    • SealedSecrets sebagai templat untuk rahasia

    • Kunci publik/Sertifikat

    • Lingkup

  • Instalasi

    • minuman rumahan

    • MacPort

    • Linux

    • Instalasi dari sumber

    • Kustomisasi

    • Bagan Helm

    • Pengendali

    • Kubeseal

  • Meningkatkan

  • Penggunaan

    • Mengelola rahasia yang ada

    • Menambal rahasia yang ada

    • Perbarui rahasia yang ada

    • Mode mentah (eksperimental)

    • Validasi Rahasia Tersegel

  • Rotasi Rahasia

    • Menyegel pembaruan kunci

    • Rotasi rahasia pengguna

    • Pembaruan kunci awal

    • Kesalahpahaman umum tentang pembaruan kunci

    • Manajemen kunci manual (lanjutan)

    • Enkripsi ulang (lanjutan)

  • Detail (lanjutan)

    • kripto

  • Berkembang

  • Pertanyaan Umum

    • Apakah Anda masih dapat mendekripsi jika Anda tidak lagi memiliki akses ke cluster Anda?

    • Bagaimana cara membuat cadangan SealedSecrets saya?

    • Bisakah saya mendekripsi rahasia saya secara offline dengan kunci cadangan?

    • Flag apa saja yang tersedia untuk kubeeal?

    • Bagaimana cara memperbarui bagian file JSON/YAML/TOML/.. yang dienkripsi dengan rahasia tersegel?

    • Bisakah saya membawa sertifikat saya sendiri (yang sudah dibuat sebelumnya)?

    • Bagaimana cara menggunakan kubeseal jika pengontrol tidak berjalan dalam namespace kube-system ?

    • Bagaimana cara memverifikasi gambar?

    • Cara menggunakan satu pengontrol untuk subset namespace

    • Dapatkah saya mengonfigurasi percobaan membuka segel pengontrol

  • Masyarakat

    • Proyek terkait

Ringkasan

Rahasia Tertutup terdiri dari dua bagian:

  • Pengontrol/operator sisi cluster

  • Utilitas sisi klien: kubeseal

Utilitas kubeseal menggunakan kripto asimetris untuk mengenkripsi rahasia yang hanya dapat didekripsi oleh pengontrol.

Rahasia terenkripsi ini dikodekan dalam sumber daya SealedSecret , yang dapat Anda lihat sebagai resep untuk membuat rahasia. Berikut tampilannya:

 apiVersion: bitnami.com/v1alpha1kind: SealedSecretmetadata: name: mysecret namespace: mynamespacespec: dienkripsiData: foo: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq.....

Setelah dibuka segelnya, ini akan menghasilkan rahasia yang setara dengan ini:

 apiVersion: v1kind: Secretmetadata: name: mysecret namespace: mynamespacedata: foo: YmFy # <- base64 dikodekan "bar"

Rahasia kubernetes normal ini akan muncul di cluster setelah beberapa detik, Anda dapat menggunakannya seperti Anda menggunakan rahasia apa pun yang akan Anda buat secara langsung (misalnya mereferensikannya dari Pod ).

Lompat ke bagian Instalasi untuk memulai dan menjalankannya.

Bagian Penggunaan mengeksplorasi lebih detail bagaimana Anda membuat sumber daya SealedSecret .

SealedSecrets sebagai templat untuk rahasia

Contoh sebelumnya hanya berfokus pada item rahasia terenkripsi itu sendiri, namun hubungan antara sumber daya kustom SealedSecret dan Secret yang dibuka segelnya serupa dalam banyak hal (namun tidak semuanya) dengan Deployment vs Pod yang sudah dikenal.

Secara khusus, anotasi dan label sumber daya SealedSecret tidak sama dengan anotasi Secret yang dihasilkan darinya.

Untuk menangkap perbedaan ini, objek SealedSecret memiliki bagian template yang mengkodekan semua bidang yang Anda ingin agar pengontrol masukkan ke dalam Secret yang tidak disegel.

Pustaka fungsi Sprig tersedia selain fungsi Templat Teks Go default.

Blok metadata disalin apa adanya (bidang ownerReference akan diperbarui kecuali dinonaktifkan).

Bidang rahasia lainnya ditangani secara individual. Bidang type dan bidang immutable disalin, dan bidang data dapat digunakan untuk membuat templat nilai kompleks pada Secret . Semua bidang lainnya saat ini diabaikan.

 apiVersion: bitnami.com/v1alpha1kind: SealedSecretmetadata: name: mysecret namespace: mynamespace annotations: "kubectl.kubernetes.io/last-applied-configuration": ....spec: dienkripsiData: .dockerconfigjson: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq.... .template: ketik: kubernetes.io/dockerconfigjson immutable: true # ini adalah contoh label dan anotasi yang akan ditambahkan ke keluaran metadata rahasia: labels: "jenkins.io/credentials-type": usernamePassword annotations: "jenkins. io/credentials-description": kredensial dari Kubernetes

Pengontrol akan membuka segelnya menjadi seperti:

 apiVersion: v1kind: Secretmetadata: name: mysecret namespace: mynamespace labels: "jenkins.io/credentials-type": usernamePassword anotasi: "jenkins.io/credentials-description": kredensial dari pemilik KubernetesReferensi:
  - apiVersion: bitnami.com/v1alpha1 pengontrol: jenis sebenarnya: SealedSecret nama: mysecret uid: 5caff6a0-c9ac-11e9-881e-42010aac003etype: kubernetes.io/dockerconfigjsonimmutable: truedata: .dockerconfigjson: ewogICJjcmVk...

Seperti yang Anda lihat, sumber daya Secret yang dihasilkan adalah "objek yang bergantung" pada SealedSecret dan oleh karena itu akan diperbarui dan dihapus setiap kali objek SealedSecret diperbarui atau dihapus.

Kunci publik/Sertifikat

Sertifikat kunci (bagian kunci publik) digunakan untuk menyegel rahasia, dan harus tersedia di mana pun kubeseal akan digunakan. Sertifikat bukanlah informasi rahasia, meskipun Anda perlu memastikan bahwa Anda menggunakan sertifikat yang benar.

kubeseal akan mengambil sertifikat dari pengontrol saat runtime (memerlukan akses aman ke server API Kubernetes), yang nyaman untuk penggunaan interaktif, namun diketahui rapuh ketika pengguna memiliki cluster dengan konfigurasi khusus seperti cluster GKE pribadi yang memiliki firewall di antaranya bidang kontrol dan node.

Alur kerja alternatifnya adalah dengan menyimpan sertifikat di suatu tempat (misalnya disk lokal) dengan kubeseal --fetch-cert >mycert.pem , dan menggunakannya secara offline dengan kubeseal --cert mycert.pem . Sertifikat juga dicetak ke log pengontrol saat startup.

Sejak sertifikat v0.9.x diperbarui secara otomatis setiap 30 hari. Merupakan praktik yang baik jika Anda dan tim Anda memperbarui sertifikat offline secara berkala. Untuk membantu Anda dalam hal tersebut, karena kubeseal v0.9.2 juga menerima URL. Anda dapat mengatur otomatisasi internal untuk menerbitkan sertifikat di tempat yang Anda percaya.

 kubeseal --cert https://your.intranet.company.com/sealed-secrets/your-cluster.cert

Itu juga mengenali env var SEALED_SECRETS_CERT . (tip pro: lihat juga direnv).

CATATAN : kami sedang berupaya menyediakan mekanisme manajemen kunci yang memindahkan enkripsi ke modul berbasis HSM atau solusi kripto cloud terkelola seperti KMS.

Lingkup

SealedSecrets berasal dari POV pengguna akhir sebagai perangkat "hanya tulis".

Idenya adalah bahwa SealedSecret hanya dapat didekripsi oleh pengontrol yang berjalan di cluster target dan tidak ada orang lain (bahkan penulis aslinya) yang dapat memperoleh Rahasia asli dari SealedSecret.

Pengguna mungkin atau mungkin tidak memiliki akses langsung ke cluster target. Lebih khusus lagi, pengguna mungkin atau mungkin tidak memiliki akses ke Rahasia yang dibuka segelnya oleh pengontrol.

Ada banyak cara untuk mengonfigurasi RBAC di k8s, tetapi cukup umum untuk melarang pengguna dengan hak istimewa rendah membaca Rahasia. Memberi pengguna satu atau lebih namespace yang memiliki hak istimewa lebih tinggi juga merupakan hal yang umum, yang memungkinkan mereka membuat dan membaca rahasia (dan/atau membuat penerapan yang dapat mereferensikan rahasia tersebut).

Sumber daya SealedSecret terenkripsi dirancang agar aman untuk dilihat tanpa memperoleh pengetahuan apa pun tentang rahasia yang disembunyikannya. Ini menyiratkan bahwa kami tidak dapat mengizinkan pengguna membaca SealedSecret yang dimaksudkan untuk namespace yang tidak dapat mereka akses dan hanya memasukkan salinannya ke dalam namespace tempat mereka dapat membaca rahasia.

Rahasia-rahasia yang tersegel berperilaku seolah-olah setiap namespace memiliki kunci enkripsi independennya sendiri dan dengan demikian, setelah Anda menyegel rahasia untuk namespace, rahasia tersebut tidak dapat dipindahkan ke namespace lain dan didekripsi di sana.

Secara teknis kami tidak menggunakan kunci pribadi independen untuk setiap namespace, namun kami menyertakan nama namespace selama proses enkripsi, sehingga secara efektif mencapai hasil yang sama.

Selain itu, namespace bukan satu-satunya tingkat di mana konfigurasi RBAC dapat menentukan siapa yang dapat melihat rahasia apa. Faktanya, ada kemungkinan bahwa pengguna dapat mengakses rahasia bernama foo di namespace tertentu tetapi tidak dapat mengakses rahasia lain di namespace yang sama. Oleh karena itu, secara default, kami tidak dapat membiarkan pengguna dengan bebas mengganti nama sumber daya SealedSecret jika tidak, pengguna jahat akan dapat mendekripsi SealedSecret apa pun untuk namespace tersebut hanya dengan mengganti namanya untuk menimpa satu-satunya pengguna rahasia yang dapat mengaksesnya. Kami menggunakan mekanisme yang sama yang digunakan untuk memasukkan namespace ke dalam kunci enkripsi untuk juga memasukkan nama rahasia.

Meskipun demikian, ada banyak skenario di mana Anda mungkin tidak peduli dengan tingkat perlindungan ini. Misalnya, satu-satunya orang yang memiliki akses ke cluster Anda adalah admin atau mereka tidak dapat membaca sumber daya Secret sama sekali. Anda mungkin mempunyai kasus penggunaan untuk memindahkan rahasia tersegel ke namespace lain (misalnya, Anda mungkin tidak mengetahui nama namespace di awal), atau Anda mungkin tidak mengetahui nama rahasianya (misalnya, rahasia tersebut dapat berisi akhiran unik berdasarkan hash dari isi dll).

Berikut adalah cakupan yang mungkin:

  • strict (default): rahasia harus disegel dengan nama dan namespace yang sama persis. Atribut ini menjadi bagian dari data terenkripsi dan dengan demikian mengubah nama dan/atau namespace akan menyebabkan "kesalahan dekripsi".

  • namespace-wide : Anda dapat dengan bebas mengganti nama rahasia yang tersegel dalam namespace tertentu.

  • cluster-wide : rahasianya dapat dibuka segelnya di namespace mana pun dan dapat diberi nama apa pun .

Berbeda dengan batasan name dan namespace , item rahasia (yaitu kunci objek JSON seperti spec.encryptedData.my-key ) dapat diganti namanya sesuka hati tanpa kehilangan kemampuan untuk mendekripsi rahasia yang tersegel.

Cakupan dipilih dengan tanda --scope :

 kubeseal --lingkup seluruh cluster sealed-secret.json

Dimungkinkan juga untuk meminta cakupan melalui anotasi pada rahasia input yang Anda berikan ke kubeseal :

  • sealedsecrets.bitnami.com/namespace-wide: "true" -> untuk namespace-wide

  • sealedsecrets.bitnami.com/cluster-wide: "true" -> untuk cluster-wide

Kurangnya anotasi tersebut berarti mode strict . Jika keduanya disetel, cluster-wide akan diutamakan.

CATATAN: Rilis berikutnya akan menggabungkan ini ke dalam satu anotasi sealedsecrets.bitnami.com/scope .

Instalasi

Lihat https://github.com/bitnami-labs/sealed-secrets/releases untuk rilis terbaru dan petunjuk instalasi terperinci.

Catatan dan instruksi khusus platform cloud:

  • GKE

Pengendali

Setelah Anda menerapkan manifes, manifes tersebut akan membuat sumber daya SealedSecret dan menginstal pengontrol ke dalam namespace kube-system , membuat akun layanan dan peran RBAC yang diperlukan.

Setelah beberapa saat, pengontrol akan mulai, menghasilkan pasangan kunci, dan siap dioperasikan. Jika tidak, periksa log pengontrol.

Kustomisasi

Mekanisme instalasi manifes pengontrol resmi hanyalah file YAML.

Dalam beberapa kasus, Anda mungkin perlu menerapkan penyesuaian Anda sendiri, seperti menyetel namespace khusus atau menyetel beberapa variabel env.

kubectl memiliki dukungan asli untuk itu, lihat kustomisasi.

Bagan Helm

Bagan kemudi Rahasia Tertutup sekarang secara resmi didukung dan dihosting di repo GitHub ini.

 helm repo tambahkan rahasia tersegel https://bitnami-labs.github.io/sealed-secrets

CATATAN: Skema pembuatan versi bagan helm berbeda dengan skema pembuatan versi proyek rahasia tersegel itu sendiri.

Awalnya bagan helm dikelola oleh komunitas dan versi pertama mengadopsi versi mayor 1 sedangkan proyek rahasia tersegel itu sendiri masih di mayor 0. Tidak apa-apa karena versi bagan helm itu sendiri belum tentu merupakan versinya. dari aplikasi itu sendiri. Namun hal ini membingungkan, jadi aturan pembuatan versi kami saat ini adalah:

  1. Skema versi pengontrol SealedSecret : 0.XY

  2. Skema versi bagan kemudi: 1.XY-rZ

Oleh karena itu, mungkin terdapat beberapa revisi pada diagram helm, dengan perbaikan yang hanya berlaku pada diagram helm tanpa memengaruhi manifes YAML statis atau gambar pengontrol itu sendiri.

CATATAN: Helm chart readme masih berisi pemberitahuan penghentian, tetapi tidak lagi mencerminkan kenyataan dan akan dihapus pada rilis berikutnya.

CATATAN: Bagan helm secara default menginstal pengontrol dengan nama sealed-secrets , sedangkan antarmuka baris perintah kubeseal (CLI) mencoba mengakses pengontrol dengan nama sealed-secrets-controller . Anda dapat secara eksplisit meneruskan --controller-name ke CLI:

 kubeseal --controller-name rahasia tersegel

Alternatifnya, Anda dapat mengatur fullnameOverride saat memasang bagan untuk mengganti nama. Perhatikan juga bahwa kubeseal mengasumsikan bahwa pengontrol dipasang di dalam namespace kube-system secara default. Jadi jika Anda ingin menggunakan kubeseal CLI tanpa harus meneruskan nama pengontrol dan namespace yang diharapkan, Anda harus menginstal Helm Chart seperti ini:

 helm install rahasia-tersegel -n kube-system --set-string fullnameOverride=pengendali-rahasia-tersegel-rahasia-rahasia/rahasia-tersegel
Helm Chart pada lingkungan terbatas

Di beberapa perusahaan, Anda mungkin hanya diberi akses ke satu namespace, bukan cluster penuh.

Salah satu lingkungan paling ketat yang dapat Anda temui adalah:

  • namespace dialokasikan untuk Anda dengan beberapa service account .

  • Anda tidak memiliki akses ke cluster lainnya, bahkan CRD cluster pun tidak.

  • Anda bahkan mungkin tidak dapat membuat akun layanan atau peran lebih lanjut di namespace Anda.

  • Anda diharuskan menyertakan batas sumber daya di semua penerapan Anda.

Bahkan dengan batasan ini Anda masih dapat menginstal Helm Chart rahasia yang tersegel, hanya ada satu prasyarat:

  • Cluster harus sudah menginstal CRD rahasia tersegel .

Setelah admin Anda menginstal CRD, jika belum ada, Anda dapat menginstal bagan dengan menyiapkan file konfigurasi YAML seperti ini:

 Akun layanan:
  buat: salah
  nama: {alokasi-layanan-akun}
rbac:
  buat: salah
  clusterRole: sumber daya palsu:
  batas:
    prosesor: 150m
    memori: 256Mi

Perhatikan bahwa:

  • Tidak ada akun layanan yang dibuat, melainkan akun yang dialokasikan untuk Anda yang akan digunakan.

    • {allocated-service-account} adalah nama service account yang Anda alokasikan di klaster.

  • Tidak ada peran RBAC yang dibuat baik di namespace maupun klaster.

  • Batasan sumber daya harus ditentukan.

    • Batasannya adalah contoh yang seharusnya berfungsi, namun Anda mungkin ingin meninjaunya dalam pengaturan khusus Anda.

Setelah file tersebut siap, jika Anda menamainya config.yaml Anda sekarang dapat menginstal rahasia Helm Chart yang tersegel seperti ini:

 helm install rahasia tersegel -n {allocationd-namespace} rahasia tersegel/rahasia tersegel --skip-crds -f config.yaml

Dimana {allocated-namespace} adalah nama namespace yang Anda alokasikan di cluster.

Kubeseal

minuman rumahan

Klien kubeseal juga tersedia di homebrew:

 pembuatan bir instal kubeseal

MacPort

Klien kubeseal juga tersedia di MacPorts:

 pemasangan port kubeseal

Nixpkgs

Klien kubeseal juga tersedia di Nixpkgs: ( DISCLAIMER : Tidak dikelola oleh bitnami-labs)

 nix-env -iA nixpkgs.kubeseal

Linux

Klien kubeseal dapat diinstal di Linux, menggunakan perintah di bawah ini:

 KUBESEAL_VERSION='' # Setel ini ke, misalnya, KUBESEAL_VERSION='0.23.0'curl -OL "https://github.com/bitnami-labs/sealed-secrets/releases/download/v${KUBESEAL_VERSION:?} /kubeseal-${KUBESEAL_VERSION:?}-linux-amd64.tar.gz"tar -xvzf kubeseal-${KUBESEAL_VERSION:?}-linux-amd64.tar.gz kubeseal
sudo install -m 755 kubeseal /usr/local/bin/kubeseal

Jika Anda telah menginstal curl dan jq di mesin Anda, Anda bisa mendapatkan versinya secara dinamis dengan cara ini. Ini dapat berguna untuk lingkungan yang digunakan dalam otomatisasi dan sejenisnya. 

# Fetch the latest sealed-secrets version using GitHub API
KUBESEAL_VERSION=$(curl -s https://api.github.com/repos/bitnami-labs/sealed-secrets/tags | jq -r '.[0].name' | cut -c 2-)

# Check if the version was fetched successfully
if [ -z "$KUBESEAL_VERSION" ]; then
    echo "Failed to fetch the latest KUBESEAL_VERSION"
    exit 1
fi

curl -OL "https://github.com/bitnami-labs/sealed-secrets/releases/download/v${KUBESEAL_VERSION}/kubeseal-${KUBESEAL_VERSION}-linux-amd64.tar.gz"
tar -xvzf kubeseal-${KUBESEAL_VERSION}-linux-amd64.tar.gz kubeseal
sudo install -m 755 kubeseal /usr/local/bin/kubeseal

dimana KUBESEAL_VERSION adalah tag versi rilis kubeseal yang ingin Anda gunakan. Misalnya: v0.18.0 .

Instalasi dari sumber

Jika Anda hanya menginginkan alat klien terbaru, alat tersebut dapat diinstal ke $GOPATH/bin dengan:

 pergi instal github.com/bitnami-labs/sealed-secrets/cmd/kubeseal@main

Anda dapat menentukan tag rilis atau penerapan SHA alih-alih main .

Perintah go install akan menempatkan biner kubeseal di $GOPATH/bin :

 $(go env GOPATH)/bin/kubeseal

Meningkatkan

Jangan lupa untuk memeriksa catatan rilis untuk panduan tentang kemungkinan perubahan yang dapat menyebabkan gangguan saat Anda meningkatkan alat klien dan/atau pengontrol.

Versi yang Didukung

Saat ini, hanya Sealed Secrets versi terbaru yang didukung untuk lingkungan produksi.

Kompatibilitas dengan versi Kubernetes

Pengontrol Sealed Secrets memastikan kompatibilitas dengan berbagai versi Kubernetes dengan mengandalkan API Kubernetes yang stabil. Biasanya, versi Kubernetes di atas 1.16 dianggap kompatibel. Namun, kami secara resmi mendukung versi Kubernetes yang direkomendasikan saat ini. Selain itu, versi di atas 1.24 menjalani verifikasi menyeluruh melalui proses CI kami pada setiap rilis.

Penggunaan

 # Buat Rahasia berkode json/yaml entah bagaimana:# (perhatikan penggunaan `--dry-run` - ini hanya file lokal!)echo -n bar | kubectl create secret generik mysecret --dry-run=client --from-file=foo=/dev/stdin -o json >mysecret.json# Ini bagian yang penting: kubeseal -f mysecret.json -w mysealedsecret.json# Pada titik ini mysealedsecret.json aman untuk diunggah ke Github,# posting di Twitter, dll.# Akhirnya:kubectl create -f mysealedsecret.json# Untung!kubectl dapatkan rahasia mysecret

Perhatikan SealedSecret dan Secret harus memiliki namespace dan name yang sama . Ini adalah fitur untuk mencegah pengguna lain di cluster yang sama menggunakan kembali rahasia tersegel Anda. Lihat bagian Cakupan untuk informasi lebih lanjut.

kubeseal membaca namespace dari rahasia masukan, menerima argumen eksplisit --namespace , dan menggunakan namespace default kubectl (dalam urutan itu). Label, anotasi, dll apa pun pada Secret asli dipertahankan, namun tidak secara otomatis tercermin dalam SealedSecret .

Secara desain, skema ini tidak mengautentikasi pengguna . Dengan kata lain, siapa pun dapat membuat SealedSecret yang berisi Secret apa pun yang mereka suka (asalkan namespace/namanya cocok). Terserah pada alur kerja manajemen konfigurasi Anda yang ada, aturan RBAC cluster, dll untuk memastikan bahwa hanya SealedSecret yang dimaksud yang diunggah ke cluster. Satu-satunya perubahan dari Kubernetes yang ada adalah konten Secret kini disembunyikan saat berada di luar cluster.

Mengelola rahasia yang ada

Jika Anda ingin pengontrol Sealed Secrets mengelola Secret yang sudah ada, Anda dapat memberi anotasi pada Secret Anda dengan anotasi sealedsecrets.bitnami.com/managed: "true" . Secret yang ada akan tertimpa ketika membuka segel SealedSecret dengan nama dan namespace yang sama, dan SealedSecret akan mengambil alih kepemilikan Secret tersebut (sehingga ketika SealedSecret dihapus maka Secret tersebut juga akan terhapus).

Menambal rahasia yang ada

Baru di v0.23.0

Ada beberapa kasus penggunaan di mana Anda tidak ingin mengganti seluruh Secret tetapi hanya menambahkan atau memodifikasi beberapa kunci dari Secret yang ada. Untuk ini, Anda dapat membubuhi keterangan Secret Anda dengan sealedsecrets.bitnami.com/patch: "true" . Menggunakan anotasi ini akan memastikan bahwa kunci rahasia, label dan anotasi dalam Secret yang tidak ada dalam SealedSecret tidak akan dihapus, dan yang ada dalam SealedSecret akan ditambahkan ke Secret (kunci rahasia, label dan anotasi yang ada baik di Secret dan SealedSecret akan dimodifikasi oleh SealedSecret ).

Anotasi ini tidak membuat SealedSecret mengambil alih kepemilikan Secret . Anda dapat menambahkan patch dan anotasi managed untuk mendapatkan perilaku patching sekaligus mengambil kepemilikan Secret .

Rahasia segel yang dapat melewati referensi pemilik yang ditetapkan

Jika Anda ingin SealedSecret dan Secret independen, yang berarti ketika Anda menghapus SealedSecret Secret tidak akan hilang bersamanya, maka Anda harus memberi anotasi pada Rahasia tersebut dengan anotasi yang sealedsecrets.bitnami.com/skip-set-owner-references: "true" sebelum menerapkan langkah-langkah Penggunaan. Anda masih dapat menambahkan sealedsecrets.bitnami.com/managed: "true" ke Secret Anda sehingga rahasia Anda akan diperbarui ketika SealedSecret diperbarui.

Perbarui rahasia yang ada

Jika Anda ingin menambah atau memperbarui rahasia tersegel yang ada tanpa memiliki teks jelas untuk item lainnya, Anda cukup menyalin & menempelkan item data terenkripsi baru dan menggabungkannya ke dalam rahasia tersegel yang sudah ada.

Anda harus berhati-hati dalam menyegel item yang diperbarui dengan nama dan namespace yang kompatibel (lihat catatan tentang cakupan di atas).

Anda dapat menggunakan perintah --merge-into untuk memperbarui rahasia tersegel yang ada jika Anda tidak ingin menyalin&menempel:

 gema -n bilah | kubectl buat rahasia generik mysecret --dry-run=client --from-file=foo=/dev/stdin -o json  | kubeseal > mysealedsecret.jsonecho -n baz | kubectl buat rahasia generik mysecret --dry-run=client --from-file=bar=/dev/stdin -o json  | kubeseal --merge-ke dalam mysealedsecret.json

Mode mentah (eksperimental)

Membuat Rahasia sementara dengan perintah kubectl , hanya membuangnya setelah disalurkan ke kubeseal bisa menjadi pengalaman pengguna yang tidak ramah. Kami sedang berupaya merombak pengalaman CLI. Sementara itu, kami menawarkan mode alternatif di mana kubeseal hanya peduli pada enkripsi nilai ke stdout, dan Anda bertanggung jawab untuk memasukkannya ke dalam sumber daya SealedSecret (tidak seperti sumber daya k8 lainnya).

Ini juga dapat berguna sebagai landasan untuk integrasi editor/IDE.

Sisi negatifnya adalah Anda harus berhati-hati agar konsisten dengan cakupan penyegelan, namespace, dan namanya.

Lihat Cakupan

cakupan strict (default):

 $ gema -n foo | kubeseal --raw --namespace bar --name mysecretAgBChHUWLMx...

cakupan namespace-wide :

 $ gema -n foo | kubeseal --raw --namespace bar --scope namespace-wideAgAbbFNkM54...

Sertakan anotasi sealedsecrets.bitnami.com/namespace-wide di SealedSecret

 metadata: anotasi: sealsecrets.bitnami.com/namespace-wide: "true"

cakupan cluster-wide :

 $ gema -n foo | kubeseal --raw --scope cluster-wideAgAjLKpIYV+...

Sertakan anotasi sealedsecrets.bitnami.com/cluster-wide di SealedSecret

 metadata: anotasi: sealsecrets.bitnami.com/cluster-wide: "true"

Validasi Rahasia Tersegel

Jika kamu ingin memvalidasi rahasia tersegel yang sudah ada, kubeseal memiliki flag --validate untuk membantumu.

Memberikan file bernama sealed-secrets.yaml yang berisi rahasia tersegel berikut:

 apiVersion: bitnami.com/v1alpha1kind: SealedSecretmetadata: name: mysecret namespace: mynamespacespec: dienkripsiData: foo: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq.....

Anda dapat memvalidasi apakah rahasia yang tersegel telah dibuat dengan benar atau tidak:

 $ kucing disegel-rahasia.yaml | kubeseal --validasi

Jika rahasia tersegel tidak valid, kubeseal akan menampilkan:

 $ kucing disegel-rahasia.yaml | kubeseal --validateerror: tidak dapat mendekripsi rahasia yang tersegel

Rotasi Rahasia

Anda harus selalu memutar rahasia Anda. Namun karena rahasia Anda dienkripsi dengan rahasia lain, Anda perlu memahami bagaimana kedua lapisan ini berhubungan untuk mengambil keputusan yang tepat.

DIATAS;DR:

Jika kunci pribadi penyegelan disusupi, Anda harus mengikuti petunjuk di bawah di bagian "Perpanjangan kunci awal" sebelum merotasi nilai rahasia Anda yang sebenarnya.

Fitur pembaruan dan enkripsi ulang kunci SealedSecret bukan pengganti rotasi berkala nilai rahasia Anda yang sebenarnya.

Menyegel pembaruan kunci

Kunci penyegel diperbarui secara otomatis setiap 30 hari. Artinya, kunci penyegelan baru dibuat dan ditambahkan ke kumpulan kunci penyegelan aktif yang dapat digunakan pengontrol untuk membuka segel sumber daya SealedSecret .

Kunci penyegel yang terakhir dibuat adalah kunci yang digunakan untuk menyegel rahasia baru saat Anda menggunakan kubeseal dan kunci penyegel yang sertifikatnya diunduh saat Anda menggunakan kubeseal --fetch-cert .

Waktu perpanjangan 30 hari adalah waktu default yang masuk akal, namun dapat diubah sesuai kebutuhan dengan flag --key-renew-period= untuk perintah di templat pod pengontrol SealedSecret . Bidang value dapat diberikan sebagai tanda durasi golang (misalnya: 720h30m ). Dengan asumsi kamu telah menginstal Sealed Secrets ke dalam namespace kube-system , gunakan perintah berikut untuk mengedit pengontrol Deployment, dan tambahkan parameter --key-renew-period . Setelah Anda menutup editor teks Anda, dan pengontrol Deployment telah dimodifikasi, sebuah Pod baru akan secara otomatis dibuat untuk menggantikan Pod lama. 

kubectl edit deployment/sealed-secrets-controller --namespace=kube-system

Nilai 0 akan menonaktifkan pembaruan kunci otomatis. Tentu saja, Anda mungkin memiliki kasus penggunaan yang valid untuk menonaktifkan pembaruan kunci penyegelan otomatis, tetapi pengalaman menunjukkan bahwa pengguna baru sering kali cenderung mengambil kesimpulan bahwa mereka menginginkan kendali atas pembaruan kunci, sebelum sepenuhnya memahami cara kerja rahasia tersegel. Baca lebih lanjut tentang ini di bagian kesalahpahaman umum di bawah.

Sayangnya, Anda tidak dapat menggunakan misalnya "d" sebagai unit selama berhari-hari karena tidak didukung oleh stdlib Go. Daripada memukul wajah Anda dengan telapak tangan, manfaatkan ini sebagai kesempatan untuk merenungkan kebohongan yang diyakini para programmer tentang waktu.

Kesalahpahaman yang umum terjadi adalah bahwa pembaruan kunci sering kali dianggap sebagai bentuk perputaran kunci, di mana kunci yang lama tidak hanya usang tetapi juga sebenarnya sudah buruk sehingga Anda ingin membuangnya. Tidaklah membantu jika fitur ini secara historis disebut "rotasi kunci", yang dapat menambah kebingungan.

Rahasia yang tersegel tidak dirotasi secara otomatis dan kunci lama tidak dihapus ketika kunci baru dibuat. Sumber daya SealedSecret lama masih dapat didekripsi (itu karena kunci penyegelan lama tidak dihapus).

Rotasi rahasia pengguna

Pembaruan kunci penyegelan dan rotasi SealedSecret bukanlah pengganti untuk memutar rahasia Anda yang sebenarnya.

Proposisi nilai inti dari alat ini adalah:

Enkripsikan Rahasia Anda ke dalam SealedSecret, yang aman untuk disimpan - bahkan di dalam repositori publik.

Jika Anda menyimpan sesuatu di penyimpanan kontrol versi, dan khususnya di penyimpanan publik, Anda harus berasumsi bahwa Anda tidak akan pernah bisa menghapus informasi tersebut.

Jika kunci penyegelan entah bagaimana bocor keluar dari cluster, Anda harus menganggap semua sumber daya SealedSecret Anda yang dienkripsi dengan kunci tersebut telah disusupi. Rotasi kunci penyegelan dalam cluster atau bahkan enkripsi ulang file SealedSecrets yang ada tidak dapat mengubahnya.

Praktik terbaiknya adalah dengan merotasi semua rahasia Anda yang sebenarnya secara berkala (misalnya mengubah kata sandi) dan membuat sumber daya SealedSecret baru dengan rahasia baru tersebut.

Namun jika pengontrol SealedSecret tidak memperbarui kunci penyegelan maka rotasi tersebut akan diperdebatkan, karena penyerang juga dapat mendekripsi rahasia baru tersebut. Oleh karena itu, Anda perlu melakukan keduanya: memperbarui kunci penyegel secara berkala dan memutar rahasia Anda yang sebenarnya!

Pembaruan kunci awal

Jika Anda mengetahui atau mencurigai kunci penyegel telah disusupi, Anda harus memperbarui kunci tersebut secepatnya sebelum mulai menyegel rahasia baru yang dirotasi, jika tidak, Anda juga akan memberikan penyerang akses ke rahasia baru Anda.

Kunci dapat dibuat lebih awal dengan meneruskan stempel waktu saat ini ke pengontrol ke dalam tanda yang disebut --key-cutoff-time atau env var yang disebut SEALED_SECRETS_KEY_CUTOFF_TIME . Format yang diharapkan adalah RFC1123, Anda dapat membuatnya dengan perintah date -R unix.

Kesalahpahaman umum tentang pembaruan kunci

Kunci penyegel rahasia yang tersegel bukanlah kunci kontrol akses (misalnya kata sandi). Mereka lebih seperti kunci GPG yang mungkin Anda gunakan untuk membaca email terenkripsi yang dikirimkan kepada Anda. Mari kita lanjutkan sedikit analogi email:

Bayangkan Anda memiliki alasan untuk meyakini kunci GPG pribadi Anda mungkin telah disusupi. Anda akan mendapatkan lebih banyak kerugian daripada keuntungan jika hal pertama yang Anda lakukan hanyalah menghapus kunci pribadi Anda. Semua email sebelumnya yang dikirim dengan kunci tersebut tidak lagi dapat diakses oleh Anda (kecuali Anda memiliki salinan email yang didekripsi), begitu pula email baru yang dikirim oleh teman Anda yang belum berhasil Anda beri tahu untuk menggunakan kunci baru.

Tentu saja, konten email terenkripsi tersebut tidak aman, karena penyerang mungkin sekarang dapat mendekripsinya, namun apa yang dilakukan sudah selesai. Hilangnya kemampuan Anda untuk membaca email secara tiba-tiba tentu tidak memperbaiki kerusakan yang terjadi. Bahkan lebih buruk lagi karena Anda tidak lagi mengetahui secara pasti rahasia apa yang diketahui penyerang. Apa yang benar-benar ingin Anda lakukan adalah memastikan bahwa teman Anda berhenti menggunakan kunci lama Anda dan mulai sekarang semua komunikasi lebih lanjut dienkripsi dengan pasangan kunci baru (yaitu teman Anda harus tahu tentang kunci baru tersebut).

Logika yang sama berlaku untuk SealedSecrets. Tujuan utamanya adalah untuk mengamankan rahasia "pengguna" Anda yang sebenarnya. Rahasia "penyegelan" hanyalah sebuah mekanisme, sebuah "amplop". Jika sebuah rahasia bocor, tidak ada jalan kembali, apa yang sudah dilakukan sudah selesai.

Pertama-tama Anda perlu memastikan bahwa rahasia baru tidak dienkripsi dengan kunci lama yang telah disusupi (dalam analogi email di atas, ini adalah: buat pasangan kunci baru dan berikan kunci publik baru Anda kepada semua teman Anda).

Langkah logis kedua adalah menetralisir kerusakan, yang bergantung pada sifat rahasianya. Contoh sederhananya adalah kata sandi basis data: jika Anda secara tidak sengaja membocorkan kata sandi basis data Anda, hal yang harus Anda lakukan hanyalah mengubah kata sandi basis data Anda (pada basis data; dan mencabut yang lama!) dan memperbarui sumber daya SealedSecret dengan kata sandi baru (yaitu menjalankan kubeseal lagi).

Kedua langkah tersebut telah dijelaskan di bagian sebelumnya, meskipun dengan cara yang tidak terlalu bertele-tele. Tidak ada salahnya untuk membacanya lagi, karena sekarang Anda sudah memiliki pemahaman yang lebih mendalam tentang alasan yang mendasarinya.

Manajemen kunci manual (lanjutan)

Pengontrol SealedSecret dan alur kerja terkait dirancang untuk mempertahankan kunci penyegelan lama dan menambahkan yang baru secara berkala. Anda tidak boleh menghapus kunci lama kecuali Anda tahu apa yang Anda lakukan.

Meskipun demikian, jika mau, Anda dapat mengelola (membuat, memindahkan, menghapus) kunci penyegel secara manual. Itu hanyalah rahasia k8 biasa yang berada di namespace yang sama dengan tempat pengontrol SealedSecret berada (biasanya kube-system , tetapi dapat dikonfigurasi).

Ada kasus penggunaan tingkat lanjut yang dapat Anda atasi dengan manajemen kreatif atas kunci penyegelan. Misalnya, Anda dapat berbagi kunci penyegelan yang sama di antara beberapa klaster sehingga Anda dapat menerapkan rahasia tersegel yang sama persis di beberapa klaster. Karena kunci penyegelan hanyalah rahasia k8s biasa, Anda bahkan dapat menggunakan rahasia tersegel itu sendiri dan menggunakan alur kerja GitOps untuk mengelola kunci penyegelan Anda (berguna ketika Anda ingin berbagi kunci yang sama di antara cluster yang berbeda)!

Memberi label rahasia kunci penyegelan dengan apa pun selain active secara efektif akan menghapus kunci dari pengontrol SealedSecret , tetapi kunci tersebut masih tersedia di k8s untuk enkripsi/dekripsi manual jika diperlukan.

CATATAN Pengontrol SealedSecret saat ini tidak secara otomatis mengambil kunci penyegelan yang dibuat secara manual, dihapus atau diberi label ulang. Admin harus memulai ulang pengontrol sebelum efeknya diterapkan.

Enkripsi ulang (lanjutan)

Sebelum Anda dapat menghilangkan beberapa kunci penyegel lama, Anda perlu mengenkripsi ulang SealedSecrets Anda dengan kunci pribadi terbaru.

 kubeseal --enkripsi ulang tmp.json  && mv tmp.json my_sealed_secret.json

Pemanggilan di atas akan menghasilkan file rahasia tersegel baru yang baru dienkripsi dengan kunci terbaru, tanpa membuat rahasia tersebut meninggalkan cluster ke klien. Anda kemudian dapat menyimpan file tersebut di sistem kontrol versi Anda ( kubeseal --re-encrypt tidak memperbarui objek dalam cluster).

Saat ini, kunci lama tidak dikumpulkan secara otomatis.

Sebaiknya enkripsi ulang SealedSecrets Anda secara berkala. Namun seperti disebutkan di atas, jangan terbuai dengan rasa aman yang salah: Anda harus berasumsi bahwa versi lama sumber daya SealedSecret (yang dienkripsi dengan kunci yang Anda anggap mati) masih berpotensi ada dan dapat diakses oleh penyerang. Yaitu enkripsi ulang bukanlah pengganti untuk merotasi rahasia Anda yang sebenarnya secara berkala.

Detail (lanjutan)

Pengontrol ini menambahkan sumber daya kustom SealedSecret baru. Bagian yang menarik dari SealedSecret adalah Secret yang dienkripsi secara asimetris dengan kode base64.

Pengontrol memelihara sekumpulan pasangan kunci privat/publik sebagai rahasia kubernetes. Kunci diberi label dengan sealedsecrets.bitnami.com/sealed-secrets-key dan diidentifikasi dalam label sebagai active atau compromised . Saat startup, Pengontrol rahasia yang tersegel akan...

  1. Cari kunci ini dan tambahkan ke penyimpanan lokalnya jika diberi label aktif.

  2. Buat kunci baru

  3. Mulai siklus rotasi kunci

Crypto

Rincian lebih lanjut tentang crypto dapat ditemukan di sini.

Berkembang

Pedoman pengembangan dapat ditemukan di panduan pengembang.

Pertanyaan Umum

Dapatkah saya mengenkripsi beberapa rahasia sekaligus, dalam satu file YAML / JSON?

Ya kamu bisa! Jatuhkan rahasia sebanyak yang Anda suka dalam satu file. Pastikan untuk memisahkannya melalui --- untuk YAML dan sebagai tambahan, objek tunggal di JSON.

Apakah Anda masih dapat mendekripsi jika Anda tidak lagi memiliki akses ke cluster Anda?

Tidak, kunci pribadi hanya disimpan dalam rahasia yang dikelola oleh controller (kecuali Anda memiliki cadangan lain dari objek K8S Anda). Tidak ada pintu belakang - tanpa kunci pribadi yang digunakan untuk mengenkripsi sealedsecrets yang diberikan, Anda tidak dapat mendekripsi. Jika Anda tidak bisa mendapatkan rahasia dengan kunci enkripsi, dan Anda juga tidak dapat sampai ke versi rahasia rahasia Anda hidup di cluster, maka Anda perlu meregenerasi kata sandi baru untuk semuanya, tutupnya lagi dengan yang baru kunci penyegelan, dll.

Bagaimana saya bisa melakukan cadangan sealedsecrets saya?

Jika Anda ingin membuat cadangan kunci pribadi enkripsi, mudah dilakukan dari akun dengan akses yang sesuai:

 Kubectl Get Secret -N Kube-System -L SealedSecrets.bitnami.com/sealed-secrets-key -o Yaml> Main.keyecho "---" >> Main.key
Kubectl Get Secret -N Kube-System Sealed-secret-Key -O yaml >> Main.key

Catatan: Anda memerlukan pernyataan kedua hanya jika Anda pernah menginstal sekelompok tertutup lebih tua dari versi 0.9.x pada cluster Anda.

Catatan: File ini akan berisi kunci publik + pengontrol dan harus dijaga OMG-aman!

Catatan: Setelah menyegel pembaruan kunci, Anda harus membuat ulang cadangan Anda. Jika tidak, cadangan Anda tidak akan dapat mendekripsi rahasia baru yang disegel.

Untuk memulihkan dari cadangan setelah beberapa bencana, kembalikan rahasia itu sebelum memulai pengontrol - atau jika pengontrol sudah dimulai, ganti rahasia yang baru dibuat dan restart pengontrol:

  • Untuk penempatan Helm:

     Kubectl berlaku -f main.key
Kubectl Delete pod -n Kube -System -L app.kubernetes.io/name=sealed -secrets

  • Untuk penempatan melalui controller.yaml manifes

     Kubectl berlaku -f main.key
Kubectl Delete Pod -N Kube-System -L Nama = Sealed-Secrets-Controller

Dapatkah saya mendekripsi rahasia saya secara offline dengan kunci cadangan?

Saat memperlakukan sekelompok tertutup sebagai sistem penyimpanan jangka panjang untuk rahasia bukanlah kasus penggunaan yang direkomendasikan, beberapa orang memang memiliki persyaratan yang sah untuk dapat memulihkan rahasia ketika cluster K8S turun dan memulihkan cadangan ke dalam penyebaran pengontrol SealedSecret tidak ada. praktis.

Jika Anda telah mencadangkan satu atau lebih kunci pribadi Anda (lihat pertanyaan sebelumnya), Anda dapat menggunakan kubeseal --recovery-unseal --recovery-private-key file1.key,file2.key,... perintah untuk mendekripsi a File Rahasia Tertutup.

Bendera apa yang tersedia untuk Kubeseal?

Anda dapat memeriksa bendera yang tersedia menggunakan kubeseal --help .

Bagaimana cara memperbarui bagian JSON/YAML/TOML/.. File dienkripsi dengan rahasia yang disegel?

Sumber daya Secret Kubernetes berisi banyak item, pada dasarnya peta datar pasangan kunci/nilai. SealedSecrets beroperasi pada level itu, dan tidak peduli apa yang Anda masukkan ke dalam nilainya. Dengan kata lain itu tidak dapat memahami file konfigurasi terstruktur yang mungkin Anda taruh secara rahasia dan dengan demikian tidak dapat membantu Anda memperbarui bidang individual di dalamnya.

Karena ini adalah masalah umum, terutama ketika berhadapan dengan aplikasi warisan, kami menawarkan contoh solusi yang mungkin.

Dapatkah saya membawa sertifikat saya sendiri (pra-dihasilkan)?

Ya, Anda dapat memberikan pengontrol dengan sertifikat Anda sendiri, dan itu akan mengkonsumsinya. Silakan periksa di sini untuk solusi.

Bagaimana cara menggunakan Kubeseal jika pengontrol tidak berjalan di dalam namespace kube-system ?

Jika Anda menginstal controller dalam namespace yang berbeda dari kube-system default, Anda perlu menyediakan namespace ini ke alat Commandline kubeseal . Ada dua opsi:

  1. Anda dapat menentukan namespace melalui opsi baris perintah --controller-namespace :

 Kubeseal --controller-namespace Sealed-secrets  mysealedsecret.json

  1. Variabel lingkungan SEALED_SECRETS_CONTROLLER_NAMESPACE :

 Ekspor Sealed_Secrets_Controller_Namespace =-secrets
Kubeseal  mysealedsecret.json

Bagaimana cara memverifikasi gambar?

Gambar kami sedang ditandatangani menggunakan COSIGN. Tanda tangan telah disimpan dalam registri wadah GitHub kami.

Gambar hingga dan termasuk v0.20.2 ditandatangani menggunakan COSIGN V1. Gambar yang lebih baru ditandatangani dengan COSIGN V2.

Cukup sederhana untuk memverifikasi gambar:

 # Ekspor COSIGN_VARIABLE Mengatur Tanda Registri Kontainer GitHub PathExport cosign_repository = ghcr.io/bitnami-labs/disegel-secret-controller/tanda# verifikasi gambar yang diunggah dalam ghcrcosign verifikasi --key .github/alur kerja/cosign.pub ghcr. IO/BITNAMI-LABS/SEALED-SECRETS-CONTROLLER: Terbaru# Verifikasi gambar yang diunggah di Dockerhubcosign Verifikasi --Key .github/workflows/cosign.pub docker.io/bitnami/sealed-secrets-controller:latest

Cara menggunakan satu pengontrol untuk subset namespaces

Jika Anda ingin menggunakan satu pengontrol untuk lebih dari satu namespace, tetapi tidak semua namespaces, Anda dapat menyediakan ruang nama tambahan menggunakan bendera baris perintah --additional-namespaces=,,<...> . Pastikan Anda memberikan peran dan sel -inti yang tepat di ruang nama target, sehingga pengontrol dapat mengelola rahasia di sana.

Dapatkah saya mengonfigurasi pengontrol yang tidak segar?

Jawabannya adalah ya, Anda dapat mengonfigurasi jumlah retries di pengontrol Anda menggunakan flag --max-unseal-retries . Bendera ini memungkinkan Anda untuk mengonfigurasi jumlah retries maksimum untuk membuka segel rahasia Anda.

Masyarakat

  • #-secret-secrets di Kubernetes Slack

Klik di sini untuk mendaftar ke Kubernetes Slack Org.

Proyek terkait

  • kubeseal-convert : https://github.com/eladleev/kubeseal-convert

  • Ekstensi Kode Studio Visual: https://marketplace.visualstudio.com/items?itemname=codecontemplator.kubeseal

  • WebSeal: Menghasilkan Rahasia di Browser: https://socialgouv.github.io/webseal

  • Implementasi TypeScript hybridencrypt: https://github.com/socialgouv/aes-gcm-rsa-oaep

  • [Depracated] Operator Rahasia Tertutup: https://github.com/disposab1e/sealed-secrets-operator-helm

Memperluas
Informasi Tambahan
Aplikasi Terkait
Direkomendasikan untuk Anda
Informasi Terkait Semua
Komentar Pengguna