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 arus lalu lintas jaringan antar layanan. Yang kedua melibatkan enkripsi lalu lintas saat sedang dalam perjalanan. Mekanisme untuk menerapkan langkah-langkah keamanan ini pada EKS bervariasi tetapi sering kali mencakup item-item berikut:

Kontrol lalu lintas

Enkripsi jaringan

Kebijakan jaringan

Di dalam klaster Kubernetes, semua komunikasi Pod ke Pod diperbolehkan secara default. Meskipun fleksibilitas ini dapat membantu mempromosikan eksperimen, itu tidak dianggap aman. Kebijakan jaringan Kubernetes memberi Anda mekanisme untuk membatasi lalu lintas jaringan antar Pod (sering disebut sebagai lalu lintas Timur/Barat) 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 keduanya. Kebijakan Jaringan dapat diterapkan pada koneksi Inbound atau Outbound ke pod, sering disebut aturan Ingress dan Egress.

Dengan dukungan kebijakan jaringan native dari Amazon VPC CNI Plugin, Anda dapat menerapkan kebijakan jaringan untuk mengamankan lalu lintas jaringan di klaster kubernetes. Ini terintegrasi dengan API Kebijakan Jaringan Kubernetes hulu, memastikan kompatibilitas dan kepatuhan terhadap standar Kubernetes. Anda dapat menentukan kebijakan menggunakan pengenal 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 adalah yang berasal dari node pod dan yang diizinkan oleh aturan ingress. Hal yang sama berlaku untuk aturan jalan 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 Istimewa Paling Sedikit

Buat kebijakan penolakan default

Seperti halnya kebijakan RBAC, disarankan untuk mengikuti 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 namespace.

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

default-menyangkal

Buat aturan untuk mengizinkan kueri DNS

Setelah Anda memiliki aturan penolakan semua default, Anda dapat mulai membuat 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

allow-dns-access

Tambahkan aturan secara bertahap untuk memungkinkan aliran lalu lintas antar namespace/pod secara selektif

Memahami persyaratan aplikasi dan membuat aturan masuk dan keluar berbutir halus sesuai kebutuhan. Contoh di bawah ini menunjukkan cara membatasi lalu lintas masuk pada port 80 ke app-one dari. client-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

allow-ingress-app-one

Pemantauan 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 agen simpul

Aktifkan log manajer pengontrol bidang Kontrol EKS untuk mendiagnosis fungsionalitas kebijakan jaringan. Anda dapat mengalirkan 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 yang diselesaikan menjadi Kebijakan Jaringan, status rekonsiliasi kebijakan, dan 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 CloudWatchWawasan Kontainer untuk memberikan wawasan tentang penggunaan yang terkait dengan Kebijakan Jaringan.

Amazon VPC CNI juga mengirimkan SDK yang menyediakan antarmuka untuk berinteraksi dengan program eBPF pada node. SDK diinstal saat aws-node dikerahkan ke node. Anda dapat menemukan biner SDK yang diinstal di bawah /opt/cni/bin direktori pada node. Saat diluncurkan, SDK menyediakan 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 paket yang diterima/dijatuhkan. 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 Logs mungkin tidak cukup dengan sendirinya. Calico Enterprise memperluas Flow Logs dengan label pod dan metadata lainnya, sehingga 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 klaster. Grup keamanan juga digunakan untuk mengontrol lalu lintas antara node pekerja, dan sumber daya VPC lainnya, dan alamat IP eksternal. Saat Anda menyediakan kluster EKS (dengan Kubernetes versi 1.14-eks.3 atau lebih tinggi), grup keamanan klaster akan dibuat secara otomatis untuk Anda. Grup keamanan ini memungkinkan komunikasi yang tidak terkekang antara bidang kontrol EKS dan node dari grup node terkelola. Untuk mempermudah, Anda disarankan untuk 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 control plane dan grup keamanan grup node dapat ditemukan di https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html. Aturan minimum untuk grup keamanan bidang kontrol memungkinkan 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 kubelet. Demikian pula, aturan grup node 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 klaster dan layanan yang dijalankan di luar klaster 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 sebuah PodSelector atau sebuahServiceAccountSelector. Menyetel selector ke {} akan menetapkan SGs referensi SecurityGroupPolicy ke semua pod di namespace atau semua Account Layanan di namespace. Pastikan Anda telah membiasakan diri dengan semua pertimbangan sebelum menerapkan grup keamanan untuk pod.

Meskipun grup keamanan untuk pod menawarkan cara asli AWS untuk mengontrol lalu lintas jaringan di dalam dan di luar klaster Anda tanpa overhead daemon kebijakan, opsi lain tersedia. Misalnya, mesin kebijakan Cilium memungkinkan Anda untuk 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 jalan keluar jaringan ke domain atau alamat IP tertentu yang sepenuhnya memenuhi syarat. Untuk informasi lebih lanjut tentang opsi ini, baca seri tiga bagian tentang kontrol lalu lintas jalan keluar di Istio.

Kapan menggunakan Kebijakan Jaringan vs Grup Keamanan untuk Pod?

Kapan menggunakan kebijakan jaringan Kubernetes

Kapan menggunakan grup AWS Security 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 defense-in-depth strategi yang kuat untuk aplikasi Anda yang berjalan di EKS.

Penegakan Kebijakan Service Mesh 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 observabilitas, 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 (network) dan Layer 4 (transport). 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 open source 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 Namespace, Pod, akun layanan, atau secara global. Ketika kebijakan dicakup ke akun layanan, kebijakan tersebut mengaitkan seperangkat 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 Cilium, juga telah memperluas kebijakan jaringan untuk menyertakan dukungan sebagian 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 yang umum di. https://github.com/ahmetb/kubernetes-network-policy-recipes Seperangkat aturan serupa untuk Calico tersedia di https://docs.projectcalico. org/security/calico-kebijakan jaringan.

Migrasi ke Mesin Kebijakan Jaringan Amazon VPC CNI

Untuk menjaga konsistensi dan menghindari perilaku komunikasi pod yang tidak terduga, disarankan untuk menggunakan hanya satu Network Policy Engine di klaster Anda. Jika Anda ingin bermigrasi dari 3P ke VPC CNI Network Policy Engine, sebaiknya Anda mengonversi 3P NetworkPolicy CRDs yang sudah ada menjadi resource Kubernetes sebelum mengaktifkan dukungan kebijakan jaringan VPC CNI. NetworkPolicy Dan, uji kebijakan yang dimigrasi dalam klaster pengujian terpisah sebelum menerapkannya di lingkungan produksi Anda. Ini memungkinkan Anda untuk mengidentifikasi dan mengatasi potensi masalah atau ketidakkonsistenan dalam perilaku komunikasi pod.

Alat Migrasi

Untuk membantu proses migrasi Anda, kami telah mengembangkan alat bernama K8s Network Policy Migrator yang mengubah kebijakan jaringan Anda yang ada menjadi kebijakan Calico/Cilium jaringan asli CRDs 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 dengan 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 GitHubmasalah. Umpan balik Anda sangat berharga bagi kami dan akan membantu dalam peningkatan berkelanjutan dari layanan kami.

Sumber Daya Tambahan

Enkripsi bergerak

Aplikasi yang perlu mematuhi PCI, HIPAA, atau peraturan lain mungkin perlu mengenkripsi data saat sedang dalam perjalanan. Saat ini TLS adalah pilihan de facto untuk mengenkripsi lalu lintas di 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.

Contoh Nitro

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

Antarmuka Jaringan Kontainer () CNIs

WeaveNetdapat dikonfigurasi untuk secara otomatis mengenkripsi semua lalu lintas menggunakan NaCl enkripsi untuk lalu lintas lengan, dan IPsec ESP untuk lalu lintas datapath cepat.

Layanan Mesh

Enkripsi dalam perjalanan juga dapat diimplementasikan dengan mesh layanan seperti App Mesh, Linkerd v2, dan Istio. AppMesh mendukung mTL dengan sertifikat X.509 atau Envoy's Secret Discovery Service (SDS). Linkerd dan Istio keduanya memiliki dukungan untuk mTL.

aws-app-mesh-examplesGitHub Repositori menyediakan panduan untuk mengonfigurasi mTL menggunakan sertifikat X.509 dan SPIRE sebagai penyedia SDS dengan wadah Utusan Anda:

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

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

Pengontrol Ingress dan Load Balancer

Pengontrol Ingress adalah cara bagi Anda untuk secara cerdas merutekan HTTP/S traffic that emanates from outside the cluster to services running inside the cluster. Oftentimes, these Ingresses are fronted by a layer 4 load balancer, like the Classic Load Balancer or the Network Load Balancer (NLB). Encrypted traffic can be terminated at different places within the network, e.g. at the load balancer, at the ingress resource, or the Pod. How and where you terminate your SSL connection will ultimately be dictated by your organization’s network security policy. For instance, if you have a policy that requires end-to-end encryption, you will have to decrypt the traffic at the Pod. This will place additional burden on your Pod as it will have to spend cycles establishing the initial handshake. Overall SSL/TLS pemrosesan yang sangat intensif CPU. Akibatnya, jika Anda memiliki fleksibilitas, coba lakukan pembongkaran SSL di Ingress atau penyeimbang beban.

Gunakan enkripsi dengan penyeimbang beban AWS Elastic

AWS Application Load Balancer (ALB) dan Network Load Balancer (NLB) keduanya memiliki dukungan untuk enkripsi transport (SSL dan TLS). alb.ingress.kubernetes.io/certificate-arnAnotasi 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.

ACM Private CA dengan manajer sertifikat

Anda dapat mengaktifkan TLS dan mTL untuk mengamankan beban kerja aplikasi EKS Anda di ingress, 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, terkelola tanpa biaya dimuka dan pemeliharaan untuk mengelola CA Anda sendiri. Jika Anda menggunakan otoritas sertifikat Kubernetes default, ada kesempatan untuk meningkatkan keamanan Anda dan memenuhi persyaratan kepatuhan dengan ACM Private CA. ACM Private CA mengamankan kunci pribadi dalam 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.

Mode CA Berumur Pendek untuk TLS Bersama Antar Beban Kerja

Saat menggunakan ACM Private CA 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 menghasilkan 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 klaster 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 ACM Private CA. Setelah Anda memiliki CA Pribadi, instal cert-manager menggunakan instruksi instalasi reguler. Setelah menginstal cert-manager, instal plugin Cert-Manager Private CA Kubernetes dengan mengikuti petunjuk penyiapan di. GitHub Plugin ini memungkinkan manajer sertifikat meminta sertifikat pribadi dari ACM Private CA.

Sekarang setelah Anda memiliki Private CA dan kluster EKS dengan cert-manager dan plugin yang diinstal, saatnya untuk mengatur izin dan membuat penerbit. Perbarui izin IAM dari peran node EKS untuk memungkinkan akses ke ACM Private CA. 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": "<CA_ARN>"
        }
    ]
}

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

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

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

Kluster EKS Anda dikonfigurasi untuk meminta sertifikat dari Private CA. Sekarang Anda dapat menggunakan Certificate sumber daya cert-manager untuk menerbitkan 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 manajer sertifikat. Lihat contoh di sini.

ACM Private CA 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 ACM Private CA sebagai root CA untuk mTL di antara 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 lebih jelasnya.

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 menetapkan satu ke beban kerja Anda. Selain itu, akun layanan secara otomatis memasang token terkait. Token ini digunakan oleh akun layanan untuk beban kerja untuk mengautentikasi terhadap Kubernetes API. Akun layanan mungkin cukup sebagai identitas untuk Kubernetes tetapi Istio memiliki sistem manajemen identitas dan CA sendiri. Ketika beban kerja dimulai dengan proxy sespan utusannya, ia membutuhkan 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 pesawat 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 lolos 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 perjalanan antara layanan yang berkomunikasi.

Alur default untuk Permintaan Penandatanganan Sertifikat Istio:

Cara Kerja Penandatanganan Sertifikat di Istio dengan ACM Private CA

Anda dapat menggunakan add-on cert-manager yang disebut agen Permintaan Penandatanganan Sertifikat Istio (istio-csr) untuk mengintegrasikan Istio dengan ACM Private CA. Agen ini memungkinkan beban kerja Istio dan komponen bidang kontrol diamankan dengan emiten manajer sertifikat, dalam hal ini ACM Private CA. Agen istio-csr mengekspos layanan yang sama dengan yang dilayani istiod dalam konfigurasi default untuk memvalidasi masuk. CSRs 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 AWS Private CA. Manajer sertifikat menggunakan plugin ini untuk meminta sertifikat TLS dari ACM Private CA. Plugin penerbit akan berkomunikasi dengan layanan ACM Private CA untuk meminta sertifikat yang ditandatangani untuk beban kerja. Setelah sertifikat ditandatangani, sertifikat 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 Petunjuk Pengaturan CA Pribadi

Permintaan penandatanganan sertifikat Istio

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

Alat dan sumber daya