Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Keamanan jaringan

Keamanan jaringan memiliki beberapa aspek. Yang pertama melibatkan penerapan aturan yang membatasi aliran lalu lintas jaringan antar layanan. Yang kedua melibatkan enkripsi lalu lintas saat sedang transit. Mekanisme untuk menerapkan langkah-langkah keamanan ini pada EKS bervariasi tetapi sering mencakup item berikut:

Kontrol lalu lintas

Enkripsi jaringan

Kebijakan jaringan

Dalam cluster Kubernetes, semua komunikasi Pod ke Pod diizinkan secara default. Meskipun fleksibilitas ini dapat membantu mempromosikan eksperimen, itu tidak dianggap aman. Kebijakan jaringan Kubernetes memberi Anda mekanisme untuk membatasi lalu lintas jaringan antara Pod (sering disebut sebagai East/West lalu lintas) serta antara Pod dan layanan eksternal. Kebijakan jaringan Kubernetes beroperasi pada lapisan 3 dan 4 dari model OSI. Kebijakan jaringan menggunakan pod, pemilih namespace dan label untuk mengidentifikasi pod sumber dan tujuan, tetapi juga dapat menyertakan alamat IP, nomor port, protokol, atau kombinasi dari ini. Kebijakan Jaringan dapat diterapkan pada koneksi Inbound atau Outbound ke pod, sering disebut aturan Ingress dan Egress.

Dengan dukungan kebijakan jaringan asli dari Plugin Amazon VPC CNI, Anda dapat menerapkan kebijakan jaringan untuk mengamankan lalu lintas jaringan di cluster kubernetes. Ini terintegrasi dengan API Kebijakan Jaringan Kubernetes hulu, memastikan kompatibilitas dan kepatuhan terhadap standar Kubernetes. Anda dapat menentukan kebijakan menggunakan pengi dentifikasi berbeda yang didukung oleh API upstream. Secara default, semua lalu lintas masuk dan keluar diizinkan ke pod. Ketika kebijakan jaringan dengan PolicyType Ingress ditentukan, hanya koneksi yang diizinkan ke dalam pod yang berasal dari node pod dan yang diizinkan oleh aturan masuk. Hal yang sama berlaku untuk aturan keluar. Jika beberapa aturan didefinisikan, maka penyatuan semua aturan diperhitungkan saat membuat keputusan. Dengan demikian, urutan evaluasi tidak mempengaruhi hasil kebijakan.

Rekomendasi

Memulai dengan Kebijakan Jaringan - Ikuti Prinsip Hak Terkecil

Membuat kebijakan penolakan default

Seperti halnya kebijakan RBAC, disarankan untuk mengikuti prinsip-prinsip akses yang paling tidak memiliki hak istimewa dengan kebijakan jaringan. Mulailah dengan membuat kebijakan tolak semua yang membatasi semua lalu lintas masuk dan keluar dengan dalam namespace.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

default-tolak

Buat aturan untuk mengizinkan kueri DNS

Setelah aturan tolak semua default diterapkan, Anda dapat memulai layering pada aturan tambahan, seperti aturan yang memungkinkan pod untuk menanyakan CoreDNS untuk resolusi nama.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-access
  namespace: default
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

izinkan-dns-akses

Tambahkan aturan secara bertahap untuk secara selektif memungkinkan aliran lalu lintas antara namespaces/pods

Memahami persyaratan aplikasi dan buat aturan masuk dan keluar yang halus sesuai kebutuhan. Contoh di bawah ini menunjukkan cara membatasi lalu lintas masuk pada port 80 ke app-one dariclient-one. Ini membantu meminimalkan permukaan serangan dan mengurangi risiko akses yang tidak sah.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-app-one
  namespace: default
spec:
  podSelector:
    matchLabels:
      k8s-app: app-one
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          k8s-app: client-one
    ports:
    - protocol: TCP
      port: 80

izinkan masukan-aplikasi-satu

Memantau penegakan kebijakan jaringan

package kubernetes.admission
import data.kubernetes.networkpolicies

deny[msg] {
    input.request.kind.kind == "Pod"
    pod_label_value := {v["k8s-app"] | v := input.request.object.metadata.labels}
    contains_label(pod_label_value, "sample-app")
    np_label_value := {v["k8s-app"] | v := networkpolicies[_].spec.podSelector.matchLabels}
    not contains_label(np_label_value, "sample-app")
    msg:= sprintf("The Pod %v could not be created because it is missing an associated Network Policy.", [input.request.object.metadata.name])
}
contains_label(arr, val) {
    arr[_] == val
}

Pemecahan masalah

Pantau log vpc-network-policy-controller, node-agent

Aktifkan log pengelola pengontrol bidang Kontrol EKS untuk mendiagnosis fungsionalitas kebijakan jaringan. Anda dapat melakukan streaming log bidang kontrol ke grup CloudWatch log dan menggunakan wawasan CloudWatch Log untuk melakukan kueri lanjutan. Dari log, Anda dapat melihat objek titik akhir pod apa yang diselesaikan ke Kebijakan Jaringan, status rekonsiliasi kebijakan, dan men-debug jika kebijakan berfungsi seperti yang diharapkan.

Selain itu, Amazon VPC CNI memungkinkan Anda mengaktifkan pengumpulan dan ekspor log penegakan kebijakan ke Amazon Cloudwatch dari node pekerja EKS. Setelah diaktifkan, Anda dapat memanfaatkan CloudWatch Wawasan Kontainer untuk memberikan wawasan tentang penggunaan terkait Kebijakan Jaringan.

Amazon VPC CNI juga mengirimkan SDK yang menyediakan antarmuka untuk berinteraksi dengan program eBPF pada node. SDK diinstal saat aws-node digunakan ke node. Anda dapat menemukan biner SDK yang diinstal di bawah /opt/cni/bin direktori pada node. Saat diluncurkan, SDK memberikan dukungan untuk fungsionalitas mendasar seperti memeriksa program dan peta eBPF.

sudo /opt/cni/bin/aws-eks-na-cli ebpf progs

Log metadata lalu lintas jaringan

AWS VPC Flow Logs menangkap metadata tentang lalu lintas yang mengalir melalui VPC, seperti alamat IP sumber dan tujuan serta port bersama dengan accepted/dropped paket. Informasi ini dapat dianalisis untuk mencari aktivitas yang mencurigakan atau tidak biasa antara sumber daya dalam VPC, termasuk Pod. Namun, karena alamat IP pod sering berubah saat diganti, Flow Log mungkin tidak cukup dengan sendirinya. Calico Enterprise memperluas Flow Log dengan label pod dan metadata lainnya, membuatnya lebih mudah untuk menguraikan arus lalu lintas antar pod.

Grup keamanan

EKS menggunakan AWS VPC Security Groups (SGs) untuk mengontrol lalu lintas antara bidang kontrol Kubernetes dan node pekerja cluster. Grup keamanan juga digunakan untuk mengontrol lalu lintas antara node pekerja, dan sumber daya VPC lainnya, dan alamat IP eksternal. Saat Anda menyediakan cluster EKS (dengan Kubernetes versi 1.14-eks.3 atau lebih tinggi), grup keamanan cluster dibuat secara otomatis untuk Anda. Grup keamanan ini memungkinkan komunikasi tanpa batas antara bidang kontrol EKS dan node dari grup node yang dikelola. Untuk kesederhanaan, disarankan agar Anda menambahkan cluster SG ke semua grup node, termasuk grup node yang tidak dikelola.

Sebelum Kubernetes versi 1.14 dan EKS versi eks.3, ada grup keamanan terpisah yang dikonfigurasi untuk bidang kontrol EKS dan grup node. Aturan minimum dan yang disarankan untuk grup keamanan bidang kontrol dan grup simpul dapat ditemukan di https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html. Aturan minimum untuk grup keamanan bidang kontrol mengi zinkan port 443 masuk dari node pekerja SG. Aturan inilah yang memungkinkan kubelet berkomunikasi dengan server API Kubernetes. Ini juga mencakup port 10250 untuk lalu lintas keluar ke node pekerja SG; 10250 adalah port yang didengarkan oleh kubelet. Demikian pula, aturan grup simpul minimum memungkinkan port 10250 masuk dari bidang kontrol SG dan 443 keluar ke bidang kontrol SG. Akhirnya ada aturan yang memungkinkan komunikasi tanpa batas antara node dalam grup node.

Jika Anda perlu mengontrol komunikasi antara layanan yang berjalan di dalam cluster dan layanan yang dijalankan di luar cluster seperti database RDS, pertimbangkan grup keamanan untuk pod. Dengan grup keamanan untuk pod, Anda dapat menetapkan grup keamanan yang ada ke kumpulan pod.

Anda dapat mengontrol pod mana yang ditetapkan ke grup keamanan dengan membuat SecurityGroupPolicy objek dan menentukan a PodSelector atau aServiceAccountSelector. Menyetel pemilih ke {} akan menetapkan SG yang direferensikan di SecurityGroupPolicy ke semua pod dalam namespace atau semua Akun Layanan dalam namespace. Pastikan Anda telah membiasakan diri dengan semua pertimbangan sebelum menerapkan grup keamanan untuk pod.

Meskipun grup keamanan untuk pod menawarkan AWS-native cara untuk mengontrol lalu lintas jaringan di dalam dan di luar cluster Anda tanpa overhead daemon kebijakan, opsi lain tersedia. Misalnya, mesin kebijakan Cilium memungkinkan Anda mereferensikan nama DNS dalam kebijakan jaringan. Calico Enterprise menyertakan opsi untuk memetakan kebijakan jaringan ke grup keamanan AWS. Jika Anda telah menerapkan mesh layanan seperti Istio, Anda dapat menggunakan gateway keluar untuk membatasi keluar jaringan ke domain atau alamat IP tertentu yang memenuhi syarat. Untuk informasi lebih lanjut tentang opsi ini, baca seri tiga bagian tentang kontrol lalu lintas keluar di Isti o.

Kapan menggunakan Kebijakan Jaringan vs Grup Keamanan untuk Pod?

Kapan menggunakan kebijakan jaringan Kubernetes

Kapan menggunakan grup Keamanan AWS untuk pod (SGP)

Praktik terbaik menggunakan grup Keamanan untuk pod dan Kebijakan Jaringan

Ketika datang ke keamanan jaringan, pendekatan berlapis seringkali merupakan solusi yang paling efektif. Menggunakan kebijakan jaringan kubernetes dan SGP dalam kombinasi dapat memberikan strategi pertahanan mendalam yang kuat untuk aplikasi Anda yang berjalan di EKS.

Penegakan Kebijakan Mesh Layanan atau kebijakan jaringan Kubernetes

A service mesh adalah lapisan infrastruktur khusus yang dapat Anda tambahkan ke aplikasi Anda. Ini memungkinkan Anda untuk secara transparan menambahkan kemampuan seperti pengamatan, manajemen lalu lintas, dan keamanan, tanpa menambahkannya ke kode Anda sendiri.

Service mesh memberlakukan kebijakan pada Layer 7 (aplikasi) model OSI sedangkan kebijakan jaringan kubernetes beroperasi pada Layer 3 (jaringan) dan Lapisan 4 (transportasi). Ada banyak penawaran di ruang ini seperti AWSAppMesh, Istio, Linkerd, dll.,

Kapan menggunakan Service mesh untuk penegakan kebijakan

Pilih kebijakan jaringan Kubernetes untuk kasus penggunaan yang lebih sederhana

ThirdParty Mesin Kebijakan Jaringan

Pertimbangkan Mesin Kebijakan Jaringan Pihak Ketiga ketika Anda memiliki persyaratan kebijakan lanjutan seperti Kebijakan Jaringan Global, dukungan untuk aturan berbasis DNS Hostname, aturan Layer 7, aturan ServiceAccount berbasis, dan deny/log tindakan eksplisit, dll., Calico, adalah mesin kebijakan sumber terbuka dari Tigera yang bekerja dengan baik dengan EKS. Selain menerapkan set lengkap fitur kebijakan jaringan Kubernetes, Calico mendukung kebijakan jaringan yang diperluas dengan serangkaian fitur yang lebih kaya, termasuk dukungan untuk aturan lapisan 7, misalnya HTTP, ketika terintegrasi dengan Istio. Kebijakan Calico dapat dicakup ke ruang nama, Pod, akun layanan, atau secara global. Ketika kebijakan dicakup ke akun layanan, kebijakan tersebut mengaitkan serangkaian ingress/egress aturan dengan akun layanan tersebut. Dengan aturan RBAC yang tepat, Anda dapat mencegah tim mengesampingkan aturan ini, memungkinkan profesional keamanan TI untuk mendelegasikan administrasi ruang nama dengan aman. Isovalent, pengelola C ilium, juga telah memperluas kebijakan jaringan untuk memasukkan dukungan parSIAL untuk aturan lapisan 7, misalnya HTTP. Cilium juga memiliki dukungan untuk nama host DNS yang dapat berguna untuk membatasi lalu lintas antara Kubernetes Services/Pods dan sumber daya yang berjalan di dalam atau di luar VPC Anda. Sebaliknya, Calico Enterprise menyertakan fitur yang memungkinkan Anda memetakan kebijakan jaringan Kubernetes ke grup keamanan AWS, serta nama host DNS.

Anda dapat menemukan daftar kebijakan jaringan Kubernetes umum di Seperangkat aturan https://github.com/ahmetb/kubernetes-network-policy-recipes. serupa untuk Calico tersedia di https://docs.projectcalico.org/security/calico-network-policy.

Migrasi ke Mesin Kebijakan Jaringan Amazon VPC CNI

Untuk menjaga konsistensi dan menghindari perilaku komunikasi pod yang tidak terduga, disarankan untuk menerapkan hanya satu Mesin Kebijakan Jaringan di cluster Anda. Jika Anda ingin bermigrasi dari 3P ke VPC CNI Network Policy Engine, sebaiknya ubah NetworkPolicy CRD 3P yang ada ke NetworkPolicy sumber daya Kubernetes sebelum mengaktifkan dukungan kebijakan jaringan VPC CNI. Dan, uji kebijakan yang dimigrasi di cluster pengujian terpisah sebelum menerapkannya di lingkungan produksi Anda. Ini memungkinkan Anda mengidentifikasi dan mengatasi masalah potensial atau inkonsistensi dalam perilaku komunikasi pod.

Alat Migrasi

Untuk membantu proses migrasi Anda, kami telah mengembangkan alat bernama K8s Network Policy Migrator yang mengubah CRD kebijakan jaringan Anda yang ada menjadi kebijakan Calico/Cilium jaringan asli Kubernetes. Setelah konversi, Anda dapat langsung menguji kebijakan jaringan yang dikonversi pada cluster baru Anda yang menjalankan pengontrol kebijakan jaringan VPC CNI. Alat ini dirancang untuk membantu Anda merampingkan proses migrasi dan memastikan transisi yang lancar.

Harap dicatat bahwa alat migrasi saat ini tidak didukung oleh tim rekayasa kebijakan AWS VPC CNI Network, alat ini tersedia untuk pelanggan berdasarkan upaya terbaik. Kami mendorong Anda untuk menggunakan alat ini untuk memfasilitasi proses migrasi Anda. Jika Anda mengalami masalah atau bug dengan alat ini, kami mohon Anda membuat GitHub masalah. Umpan balik Anda sangat berharga bagi kami dan akan membantu dalam peningkatan berkelanjutan dari layanan kami.

Sumber Daya Tambahan

Enkripsi saat bergerak

Aplikasi yang harus sesuai dengan PCI, HIPAA, atau peraturan lainnya mungkin perlu mengenkripsi data saat sedang transit. Saat ini TLS adalah pilihan de facto untuk mengenkripsi lalu lintas pada kawat. TLS, seperti pendahulunya SSL, menyediakan komunikasi yang aman melalui jaringan menggunakan protokol kriptografi. TLS menggunakan enkripsi simetris di mana kunci untuk mengenkripsi data dihasilkan berdasarkan rahasia bersama yang dinegosiasikan pada awal sesi. Berikut ini adalah beberapa cara untuk mengenkripsi data di lingkungan Kubernetes.

Instans Nitro

Lalu lintas yang dipertukarkan antara jenis instance Nitro berikut, misalnya C5n, G4, I3en, M5dn, M5n, P3dn, R5dn, dan R5n, secara otomatis dienkripsi secara default. Ketika ada lompatan perantara, seperti gateway transit atau penyeimbang beban, lalu lintas tidak dienkripsi. Lihat Enkripsi dalam transit untuk detail lebih lanjut tentang enkripsi dalam transit serta daftar lengkap jenis instans yang mendukung enkripsi jaringan secara default.

Jaring Layanan

Enkripsi dalam transit juga dapat diimplementasikan dengan mesh layanan seperti App Mesh, Linkerd v2, dan Istio. AppMesh mendukung MTL dengan X.509 sertifikat atau Layanan Penemuan Rahasia Envoy (SDS). Linkerd dan Istio keduanya memiliki dukungan untuk MTL.

GitHub Repositori aws-app-mesh-examples menyediakan panduan untuk mengonfigurasi MTL menggunakan X.509 sertifikat dan SPIRE sebagai penyedia SDS dengan wadah Envoy Anda:

App Mesh juga mendukung enkripsi TLS dengan sertifikat pribadi yang dikeluarkan oleh AWS Certi ficate Manager (ACM) atau sertifikat yang disimpan di sistem file lokal node virtual.

GitHub Repositori aws-app-mesh-examples menyediakan panduan untuk mengonfigurasi TLS menggunakan sertifikat yang dikeluarkan oleh ACM dan sertifikat yang dikemas dengan wadah Envoy Anda:

Pengontrol Ingress dan Penyeimbang Beban

Pengontrol Ingress adalah cara bagi Anda untuk secara cerdas merut HTTP/S ekan lalu lintas yang berasal dari luar cluster ke layanan yang berjalan di dalam cluster. Seringkali, Ingress ini didahului oleh penyeimbang beban lapisan 4, seperti Classic Load Balancer atau Network Load Balancer (NLB). Lalu lintas terenkripsi dapat dihentikan di tempat yang berbeda dalam jaringan, misalnya di penyeimbang beban, di sumber daya masuk, atau Pod. Bagaimana dan di mana Anda menghentikan koneksi SSL Anda pada akhirnya akan ditentukan oleh kebijakan keamanan jaringan organisasi Anda. Misalnya, jika Anda memiliki kebijakan yang memerlukan enkripsi ujung ke ujung, Anda harus mendekripsi lalu lintas di Pod. Ini akan menempatkan beban tambahan pada Pod Anda karena harus menghabiskan siklus untuk membuat jabat tangan awal. Pem SSL/TLS rosesan keseluruhan sangat intensif CPU. Akibatnya, jika Anda memiliki fleksibilitas, coba lakukan offload SSL di Ingress atau load balancer.

Gunakan enkripsi dengan penyeimbang beban AWS Elastic

AWS Application Load Balancer (ALB) dan Network Load Balancer (NLB) keduanya memiliki dukungan untuk enkripsi transportasi (SSL dan TLS). A alb.ingress.kubernetes.io/certificate-arn notasi untuk ALB memungkinkan Anda menentukan sertifikat mana yang akan ditambahkan ke ALB. Jika Anda menghilangkan anotasi, pengontrol akan mencoba menambahkan sertifikat ke pendengar yang memerlukannya dengan mencocokkan sertifikat AWS Certificate Manager (ACM) yang tersedia menggunakan bidang host. Dimulai dengan EKS v1.15 Anda dapat menggunakan service.beta.kubernetes.io/aws-load-balancer-ssl-cert anotasi dengan NLB seperti yang ditunjukkan pada contoh di bawah ini.

apiVersion: v1
kind: Service
metadata:
  name: demo-app
  namespace: default
  labels:
    app: demo-app
  annotations:
     service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
     service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "<certificate ARN>"
     service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
     service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http"
spec:
  type: LoadBalancer
  ports:
  - port: 443
    targetPort: 80
    protocol: TCP
  selector:
    app: demo-app
//---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: nginx
  namespace: default
  labels:
    app: demo-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 443
              protocol: TCP
            - containerPort: 80
              protocol: TCP

Berikut ini adalah contoh tambahan untuk SSL/TLS penghentian.

CA Pribadi ACM dengan manajer sertifikat

Anda dapat mengaktifkan TLS dan MTL untuk mengamankan beban kerja aplikasi EKS Anda di input, di pod, dan di antara pod menggunakan ACM Private Certificate Authority (CA) dan cert-manager, add-on Kubernetes populer untuk mendistribusikan, memperbarui, dan mencabut sertifikat. ACM Private CA adalah CA yang sangat tersedia, aman, dan dikelola tanpa biaya di muka dan pemeliharaan untuk mengelola CA Anda sendiri. Jika Anda menggunakan otoritas sertifikat Kubernetes default, ada peluang untuk meningkatkan keamanan Anda dan memenuhi persyaratan kepatuhan dengan CA Pribadi ACM. ACM Private CA mengamankan kunci pribadi di modul keamanan perangkat keras FIPS 140-2 Level 3 (sangat aman), dibandingkan dengan kunci penyimpanan CA default yang dikodekan dalam memori (kurang aman). CA terpusat juga memberi Anda lebih banyak kontrol dan peningkatan auditabilitas untuk sertifikat pribadi baik di dalam maupun di luar lingkungan Kubernetes.

Short-Lived Mode CA untuk TLS Bersama Antara Beban Kerja

Saat menggunakan CA Pribadi ACM untuk MTL di EKS, disarankan agar Anda menggunakan sertifikat berumur pendek dengan mode CA berumur pendek. Meskipun dimungkinkan untuk mengeluarkan sertifikat berumur pendek dalam mode CA tujuan umum, menggunakan mode CA berumur pendek bekerja lebih hemat biaya (~ 75% lebih murah daripada mode umum) untuk kasus penggunaan di mana sertifikat baru perlu sering dikeluarkan. Selain itu, Anda harus mencoba menyelaraskan masa berlaku sertifikat pribadi dengan masa pakai pod di cluster EKS Anda. Pelajari lebih lanjut tentang ACM Private CA dan manfaatnya di sini.

Petunjuk Pengaturan ACM

Mulailah dengan membuat CA Pribadi dengan mengikuti prosedur yang disediakan dalam dokumen teknologi CA Pribadi ACM. Setelah Anda memiliki CA Pribadi, instal cert-manager menggunakan instruksi instalasi reguler. Setelah menginstal cert-manager, instal plugin Private CA Kubernetes cert-manager dengan mengikuti petunjuk penyiapan di. GitHub Plugin memungkinkan manajer sertifikat meminta sertifikat pribadi dari ACM Private CA.

Sekarang setelah Anda memiliki CA Pribadi dan cluster EKS dengan manajer sertifikat dan plugin diinstal, saatnya untuk mengatur izin dan membuat penerbit. Perbarui izin IAM dari peran simpul EKS untuk mengizinkan akses ke CA Pribadi ACM. Ganti <CA_ARN> dengan nilai dari CA Pribadi Anda:

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Sid": "awspcaissuer",
            "Action": [
                "acm-pca:DescribeCertificateAuthority",
                "acm-pca:GetCertificate",
                "acm-pca:IssueCertificate"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:acm-pca:us-west-2:123456789012:certificate-authority/12345678-1234-1234-1234-123456789012"
        }
    ]
}

Peran Layanan untuk Akun IAM, atau IRSA juga dapat digunakan. Silakan lihat bagian Sumber Daya Tambahan di bawah ini untuk contoh lengkap.

Buat Penerbit di Amazon EKS dengan membuat file Definisi Sumber Daya Kustom bernama cluster-issuer.yaml dengan teks berikut di dalamnya, ganti <CA_ARN> dan <Region> informasikan dengan CA Pribadi Anda.

apiVersion: awspca.cert-manager.io/v1beta1
kind: AWSPCAClusterIssuer
metadata:
          name: demo-test-root-ca
spec:
          arn: <CA_ARN>
          region: <Region>

Terapkan Penerbit yang Anda buat.

kubectl apply -f cluster-issuer.yaml

Cluster EKS Anda dikonfigurasi untuk meminta sertifikat dari CA Pribadi. Anda sekarang dapat menggunakan Certificate sumber daya cert-manager untuk mengeluarkan sertifikat dengan mengubah nilai issuerRef bidang menjadi Penerbit CA Pribadi yang Anda buat di atas. Untuk detail selengkapnya tentang cara menentukan dan meminta sumber daya Sertifikat, silakan periksa panduan Sumber Daya Sertifikat cert-manager. Lihat contoh di sini.

CA Pribadi ACM dengan Istio dan manajer sertifikat

Jika Anda menjalankan Istio di cluster EKS Anda, Anda dapat menonaktifkan bidang kontrol Istio (khususnyaistiod) agar tidak berfungsi sebagai root Certificate Authority (CA), dan mengonfigurasi CA Pribadi ACM sebagai CA root untuk MTL antar beban kerja. Jika Anda menggunakan pendekatan ini, pertimbangkan untuk menggunakan mode CA berumur pendek di ACM Private CA. Lihat bagian sebelumnya dan posting blog ini untuk detail lebih lanjut.

Cara Kerja Penandatanganan Sertifikat di Istio (Default)

Beban kerja di Kubernetes diidentifikasi menggunakan akun layanan. Jika Anda tidak menentukan akun layanan, Kubernetes akan secara otomatis menetapkannya ke beban kerja Anda. Selain itu, akun layanan secara otomatis memasang token terkait. Token ini digunakan oleh akun layanan untuk beban kerja untuk mengotentikasi terhadap API Kubernetes. Akun layanan mungkin cukup sebagai identitas untuk Kubernetes tetapi Istio memiliki sistem manajemen identitas dan CA sendiri. Ketika beban kerja dimulai dengan proxy sidecar utusan, diperlukan identitas yang ditetapkan dari Istio agar dapat dianggap dapat dipercaya dan diizinkan untuk berkomunikasi dengan layanan lain di mesh.

Untuk mendapatkan identitas ini dari Istio, istio-agent mengirimkan permintaan yang dikenal sebagai permintaan penandatanganan sertifikat (atau CSR) ke bidang kontrol Istio. CSR ini berisi token akun layanan sehingga identitas beban kerja dapat diverifikasi sebelum diproses. Proses verifikasi ini ditangani olehistiod, yang bertindak sebagai Otoritas Registrasi (atau RA) dan CA. RA berfungsi sebagai penjaga gerbang yang memastikan hanya CSR terverifikasi yang berhasil masuk ke CA. Setelah CSR diverifikasi, CSR akan diteruskan ke CA yang kemudian akan mengeluarkan sertifikat yang berisi identitas SPIFFE dengan akun layanan. Sertifikat ini disebut dokumen identitas yang dapat diverifikasi SPIFFE (atau SVID). SVID ditugaskan ke layanan yang meminta untuk tujuan identifikasi dan untuk mengenkripsi lalu lintas dalam transit antara layanan komunikasi.

Alur default untuk Permintaan Penandatanganan Sertifikat Istio:

Cara Kerja Penandatanganan Sertifikat di Istio dengan ACM Private CA

Anda dapat menggunakan add-on manajer sertifikat yang disebut agen Permintaan Penandatanganan Sertifikat Istio (istio-csr) untuk mengintegrasikan Istio dengan CA Pribadi ACM. Agen ini memungkinkan beban kerja Istio dan komponen bidang kontrol diamankan dengan penerbit manajer sertifikat, dalam hal ini ACM Private CA. A gen istio-csr mengekspos layanan yang sama yang dilayani istiod dalam konfigurasi default untuk memvalidasi CSR yang masuk. Kecuali, setelah verifikasi, itu akan mengubah permintaan menjadi sumber daya yang didukung manajer sertifikat (yaitu integrasi dengan penerbit CA eksternal).

Setiap kali ada CSR dari beban kerja, itu akan diteruskan ke istio-csr, yang akan meminta sertifikat dari ACM Private CA. Komunikasi antara istio-csr dan ACM Private CA ini diaktifkan oleh plugin penerbit CA Pribadi AWS. Manajer sertifikat menggunakan plugin ini untuk meminta sertifikat TLS dari ACM Private CA. Plugin penerbit akan berkomunikasi dengan layanan CA Pribadi ACM untuk meminta sertifikat yang ditandatangani untuk beban kerja. Setelah sertifikat ditandatangani, itu akan dikembalikan ke istio-csr, yang akan membaca permintaan yang ditandatangani, dan mengembalikannya ke beban kerja yang memulai CSR.

Alur untuk Permintaan Penandatanganan Sertifikat Istio dengan istio-csr

image: :istio-csr-with-acm-private-ca.png [Alur untuk Permintaan Penandatanganan Sertifikat Istio dengan istio-csr]

Istio dengan Instruksi Pengaturan CA Pribadi

Permintaan penandatanganan sertifikat Istio

image: :istio-csr-requests.png [Permintaan penandatanganan sertifikat Istio]

Alat dan sumber daya