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

Strategi Multi Akun

AWS merekomendasikan penggunaan strategi multi akun dan organisasi AWS untuk membantu mengisolasi dan mengelola aplikasi dan data bisnis Anda. Ada banyak manfaat menggunakan strategi multi akun:

Bagian berikut akan menjelaskan cara menerapkan strategi multi akun untuk beban kerja EKS Anda menggunakan pendekatan kluster EKS terpusat atau terpusat.

Merencanakan Strategi Akun Multi Beban Kerja untuk Multi Tenant Cluster

Dalam strategi AWS multi akun, sumber daya yang termasuk dalam beban kerja tertentu seperti bucket S3, ElastiCache cluster, dan DynamoDB Tables semuanya dibuat di akun AWS yang berisi semua sumber daya untuk beban kerja tersebut. Ini disebut sebagai akun beban kerja, dan kluster EKS dikerahkan ke akun yang disebut sebagai akun cluster. Akun cluster akan dieksplorasi di bagian selanjutnya. Menerapkan sumber daya ke akun beban kerja khusus mirip dengan menerapkan sumber daya kubernetes ke dalam namespace khusus.

Akun beban kerja kemudian dapat dipecah lebih lanjut berdasarkan siklus hidup pengembangan perangkat lunak atau persyaratan lain jika sesuai. Misalnya beban kerja tertentu dapat memiliki akun produksi, akun pengembangan, atau akun untuk hosting instance beban kerja tersebut di wilayah tertentu. Informasi lebih lanjut tersedia di whitepaper AWS ini.

Anda dapat mengadopsi pendekatan berikut saat menerapkan strategi Multi akun EKS:

Kluster EKS Terpusat

Dalam pendekatan ini, Kluster EKS Anda akan digunakan dalam satu akun AWS yang disebut. Cluster Account Menggunakan peran IAM untuk Akun Layanan (IRSA) atau EKS Pod Identities untuk memberikan kredensyal AWS sementara dan AWS Resource Access Manager (RAM) untuk menyederhanakan akses jaringan, Anda dapat mengadopsi strategi multi akun untuk klaster EKS multi tenant Anda. Akun cluster akan berisi VPC, subnet, kluster EKS, sumber daya EC2/Fargate komputasi (node pekerja), dan konfigurasi jaringan tambahan apa pun yang diperlukan untuk menjalankan kluster EKS Anda.

Dalam strategi akun multi beban kerja untuk klaster multi tenant, akun AWS biasanya selaras dengan ruang nama kubernetes sebagai mekanisme untuk mengisolasi grup sumber daya. Praktik terbaik untuk isolasi penyewa dalam cluster EKS harus tetap diikuti saat menerapkan strategi multi akun untuk klaster EKS multi penyewa.

Dimungkinkan untuk memiliki beberapa Cluster Accounts di organisasi AWS Anda, dan merupakan praktik terbaik untuk memiliki beberapa Cluster Accounts yang selaras dengan kebutuhan siklus hidup pengembangan perangkat lunak Anda. Untuk beban kerja yang beroperasi pada skala yang sangat besar, Anda mungkin memerlukan beberapa Cluster Accounts untuk memastikan bahwa ada cukup kubernetes dan kuota layanan AWS yang tersedia untuk semua beban kerja Anda.

|Pada diagram di atas, AWS RAM digunakan untuk berbagi subnet dari akun cluster ke akun beban kerja. Kemudian beban kerja yang berjalan di pod EKS menggunakan IRSA atau EKS Pod Identities dan role chaining untuk mengambil peran dalam akun beban kerja mereka dan mengakses sumber daya AWS mereka.

Menerapkan Strategi Akun Multi Beban Kerja untuk Multi Tenant Cluster

Berbagi Subnet Dengan AWS Resource Access Manager

AWS Resource Access Manager (RAM) memungkinkan Anda berbagi sumber daya di seluruh akun AWS.

Jika RAM diaktifkan untuk AWS Organization, Anda dapat membagikan Subnet VPC dari akun Cluster ke akun beban kerja Anda. Ini akan memungkinkan sumber daya AWS yang dimiliki oleh akun beban kerja Anda, seperti Amazon ElastiCache Clusters atau Amazon Relational Database Service (RDS) Database Service (RDS) untuk diterapkan ke VPC yang sama dengan kluster EKS Anda, dan dapat dikonsumsi oleh beban kerja yang berjalan di kluster EKS Anda.

Untuk berbagi sumber daya melalui RAM, buka RAM di konsol AWS akun cluster dan pilih “Berbagi Sumber Daya” dan “Buat Berbagi Sumber Daya”. Beri nama Resource Share Anda dan Pilih subnet yang ingin Anda bagikan. Pilih Berikutnya lagi dan masukkan 12 digit ID akun untuk akun beban kerja yang ingin Anda bagikan subnet, pilih berikutnya lagi, dan klik Buat berbagi sumber daya untuk menyelesaikannya. Setelah langkah ini, akun beban kerja dapat menyebarkan sumber daya ke subnet tersebut.

Berbagi RAM juga dapat dibuat secara terprogram, atau dengan infrastruktur sebagai kode.

Memilih Antara Identitas EKS Pod dan IRSA

Di re:invent 2023, AWS meluncurkan EKS Pod Identities sebagai cara yang lebih sederhana untuk mengirimkan kredensyal AWS sementara ke pod Anda di EKS. Identitas Pod IRSA dan EKS adalah metode yang valid untuk mengirimkan kredensyal AWS sementara ke pod EKS Anda dan akan terus didukung. Anda harus mempertimbangkan metode pengiriman mana yang paling sesuai dengan kebutuhan Anda.

Saat bekerja dengan kluster EKS dan beberapa akun AWS, IRSA dapat langsung mengambil peran di akun AWS selain akun tempat cluster EKS di-host secara langsung, sementara identitas EKS Pod mengharuskan Anda untuk mengonfigurasi rantai peran. Lihat dokumentasi EKS untuk perbandingan mendalam.

Mengakses Sumber Daya AWS API dengan Peran IAM Untuk Akun Layanan

Peran IAM untuk Akun Layanan (IRSA) memungkinkan Anda mengirimkan kredensyal AWS sementara ke beban kerja Anda yang berjalan di EKS. IRSA dapat digunakan untuk mendapatkan kredensi sementara untuk peran IAM di akun beban kerja dari akun cluster. Hal ini memungkinkan beban kerja Anda berjalan di kluster EKS Anda di akun klaster untuk menggunakan sumber daya AWS API, seperti bucket S3 yang dihosting di akun beban kerja, dan menggunakan autentikasi IAM untuk sumber daya seperti Amazon RDS Databases atau Amazon EFS. FileSystems

Sumber daya AWS API dan Sumber Daya lainnya yang menggunakan autentikasi IAM di akun beban kerja hanya dapat diakses oleh kredensyal untuk peran IAM di akun beban kerja yang sama, kecuali jika akses lintas akun mampu dan telah diaktifkan secara eksplisit.

Mengaktifkan IRSA untuk akses lintas akun

Untuk mengaktifkan IRSA untuk beban kerja di Akun Cluster Anda untuk mengakses sumber daya di akun Beban Kerja, Anda harus terlebih dahulu membuat penyedia identitas IAM OIDC di akun beban kerja Anda. Ini dapat dilakukan dengan prosedur yang sama untuk mengatur IRSA, kecuali Penyedia Identitas akan dibuat di akun beban kerja.

Kemudian saat mengonfigurasi IRSA untuk beban kerja Anda di EKS, Anda dapat mengikuti langkah yang sama seperti dokumentasi, tetapi gunakan id akun 12 digit dari akun beban kerja seperti yang disebutkan di bagian “Contoh Buat penyedia identitas dari cluster akun lain”.

Setelah ini dikonfigurasi, aplikasi Anda yang berjalan di EKS akan dapat langsung menggunakan akun layanannya untuk mengambil peran dalam akun beban kerja, dan menggunakan sumber daya di dalamnya.

Mengakses Sumber Daya AWS API dengan Identitas Pod EKS

EKS Pod Identities menyediakan cara lain untuk mengirimkan kredensyal AWS sementara ke beban kerja Anda yang berjalan di EKS. EKS Pod Identities terintegrasi dengan control plane EKS dan agen on-cluster sehingga pod menerima kredensi tanpa mengharuskan Anda untuk membuat atau mengelola penyedia identitas IAM OIDC. EKS Pod Identities adalah pendekatan yang direkomendasikan untuk beban kerja baru pada tipe node yang didukung, sementara IRSA tetap merupakan alternatif yang didukung penuh.

Dengan EKS Pod Identities, Anda mengaitkan akun layanan Kubernetes di klaster Anda dengan peran IAM di akun AWS yang sama dengan klaster. EKS menggunakan asosiasi ini untuk mendapatkan kredensi sementara untuk peran IAM tersebut dan mengirimkannya dengan aman ke pod yang menggunakan akun layanan. Aplikasi Anda kemudian dapat menggunakan AWS SDK standar dan rantai kredensyal default untuk memanggil AWS API; tidak diperlukan penyedia kredensyal khusus atau file konfigurasi.

Mengaktifkan Identitas Pod EKS untuk akses lintas akun

EKS Pod Identities secara native mendukung akses lintas akun dengan menggunakan peran IAM target dalam akun beban kerja dan rantai peran IAM. Saat Anda membuat asosiasi Identitas Pod untuk akun layanan Kubernetes, Anda menentukan peran IAM pod di akun klaster dan peran IAM target di akun beban kerja. EKS Pod Identity menggunakan peran pod untuk mengasumsikan peran target dan mengembalikan kredensyal sementara untuk peran target ke pod.

Lihat blog AWS ini untuk panduan dan pertimbangan terperinci tentang pendekatan ini.

Identitas ABAC dan EKS Pod untuk akses lintas akun

Saat menggunakan EKS Pod Identities untuk mengambil peran (role chaining) di akun lain sebagai bagian dari strategi multi akun, Anda memiliki opsi untuk menetapkan peran IAM unik untuk setiap akun layanan yang perlu mengakses akun lain, atau menggunakan peran IAM umum di beberapa akun layanan dan menggunakan ABAC untuk mengontrol akun apa yang dapat diakses.

Untuk menggunakan ABAC untuk mengontrol akun layanan apa yang dapat mengambil peran ke akun lain dengan rantai peran, Anda membuat pernyataan kebijakan kepercayaan peran yang hanya mengizinkan peran diasumsikan oleh peran IAM pod dari akun klaster EKS (ID akun 111122223333) saat nilai yang diharapkan ada. Kebijakan kepercayaan peran berikut hanya akan membiarkan peran IAM pod dari akun klaster EKS mengambil peran jikakubernetes-service-account, eks-cluster-arn dan kubernetes-namespace tag semuanya memiliki nilai yang diharapkan.

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:role/account-a-role"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:RequestTag/kubernetes-service-account": "PayrollApplication",
                    "aws:RequestTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/ProductionCluster",
                    "aws:RequestTag/kubernetes-namespace": "PayrollNamespace"
                }
            }
        }
    ]
}

Anda juga dapat menggunakan kebijakan sesi Identitas Pod EKS untuk memperluas cakupan izin untuk sebuah pod tanpa membuat peran IAM tambahan. Kebijakan sesi diterapkan ketika EKS Pod Identity mengambil peran dan izin yang dihasilkan adalah persimpangan kebijakan peran dan kebijakan sesi; untuk pertimbangan dan langkah-langkah terperinci, lihat kebijakan Sesi blog AWS Containers untuk Amazon EKS Pod Identity.

Saat menggunakan strategi ini, merupakan praktik terbaik untuk memastikan bahwa peran IAM umum hanya memiliki sts:AssumeRole dan sts:TagSession izin dan tidak ada akses AWS lainnya.

Penting saat menggunakan ABAC bahwa Anda mengontrol siapa yang memiliki kemampuan untuk menandai peran IAM, pengguna, dan sesi STS hanya kepada mereka yang memiliki kebutuhan ketat untuk melakukannya. Seseorang dengan kemampuan untuk mengatur kubernetes- atau eks- tag mungkin dapat menyetel tag yang identik dengan apa yang akan diteruskan selama rantai peran EKS Pod Identity dan mungkin dapat meningkatkan hak istimewa mereka. Anda dapat membatasi siapa yang memiliki akses untuk menyetel tag ini menggunakan kebijakan IAM atau Kebijakan Kontrol Layanan (SCP); misalnya mengontrol, merujuk ke dan. ProtectPodIdentitiesTagsOnRolesAndUsersSTS-Protect-EKS-pod-identities-tags

Memilih Antara Identitas EKS Pod dan IRSA

Identitas Pod IRSA dan EKS adalah opsi yang valid untuk mengirimkan kredensi AWS sementara ke beban kerja EKS Anda. EKS Pod Identities direkomendasikan untuk aplikasi baru yang berjalan pada tipe node yang didukung dan IRSA sangat cocok di mana Anda sudah memiliki OIDC dan IRSA di tempat atau berjalan pada platform yang EKS Pod Identities tidak mendukung.

Pertimbangkan hal berikut saat memutuskan mana yang akan digunakan:

IRSA dan EKS Pod Identities keduanya mendukung strategi multi-akun. Anda dapat menggunakan salah satu pendekatan secara konsisten di seluruh klaster Anda atau mengadopsi model campuran di mana beban kerja lama terus menggunakan IRSA dan beban kerja baru menggunakan EKS Pod Identities.

De-centralized Kluster EKS

Dalam pendekatan ini, kluster EKS diterapkan ke Akun AWS beban kerja masing-masing dan hidup bersama dengan sumber daya AWS lainnya seperti bucket Amazon S3, VPC, tabel Amazon DynamoDB, dll., Setiap akun beban kerja independen, mandiri, dan dioperasikan oleh tim Bisnis masing-masing. Unit/Application Model ini memungkinkan pembuatan cetak biru yang dapat digunakan kembali untuk berbagai kemampuan cluster — clusterAI/ML , pemrosesan Batch, Tujuan umum, dll, — dan menjual cluster berdasarkan persyaratan tim aplikasi. Baik tim aplikasi dan platform beroperasi dari GitOpsrepositori masing-masing untuk mengelola penerapan ke cluster beban kerja.

Dalam diagram di atas, kluster Amazon EKS dan sumber daya AWS lainnya diterapkan ke akun beban kerja masing-masing. Kemudian beban kerja yang berjalan di pod EKS menggunakan IRSA atau EKS Pod Identities untuk mengakses sumber daya AWS mereka.

GitOps adalah cara mengelola penerapan aplikasi dan infrastruktur sehingga seluruh sistem dijelaskan secara deklaratif dalam repositori Git. Ini adalah model operasional yang menawarkan Anda kemampuan untuk mengelola status beberapa klaster Kubernetes menggunakan praktik terbaik kontrol versi, artefak yang tidak dapat diubah, dan otomatisasi. Dalam model multi cluster ini, setiap klaster beban kerja di-bootstrap dengan beberapa repo Git, memungkinkan setiap tim (aplikasi, platform, keamanan, dll.,) untuk menerapkan perubahan masing-masing pada cluster.

Anda akan menggunakan peran IAM untuk Akun Layanan (IRSA) atau Identitas Pod EKS di setiap akun untuk memungkinkan beban kerja EKS Anda mendapatkan kredensil aws sementara untuk mengakses sumber daya AWS lainnya dengan aman. Peran IAM dibuat di Akun AWS beban kerja masing-masing dan memetakannya ke akun layanan k8s untuk menyediakan akses IAM sementara. Jadi, tidak diperlukan akses lintas akun dalam pendekatan ini. Ikuti peran IAM untuk dokumentasi Akun Layanan tentang cara penyiapan di setiap beban kerja untuk IRSA, dan dokumentasi EKS Pod Identities tentang cara mengatur identitas pod EKS di setiap akun.

Jaringan Terpusat

Anda juga dapat menggunakan AWS RAM untuk membagikan Subnet VPC ke akun beban kerja dan meluncurkan kluster Amazon EKS dan sumber daya AWS lainnya di dalamnya. Ini memungkinkan jaringan terpusat, konektivitas jaringan yang disederhanakan managment/administration, dan kluster EKS yang tidak terpusat. Lihat blog AWS ini untuk panduan dan pertimbangan terperinci tentang pendekatan ini.

Dalam diagram di atas, AWS RAM digunakan untuk berbagi subnet dari akun jaringan pusat ke akun beban kerja. Kemudian kluster EKS dan sumber daya AWS lainnya diluncurkan di subnet tersebut di masing-masing akun beban kerja. Pod EKS menggunakan IRSA atau EKS Pod Identities untuk mengakses sumber daya AWS mereka.

Cluster terpusat vs De-centralized EKS

Keputusan untuk menjalankan dengan Terpusat atau De-centralized akan tergantung pada kebutuhan Anda. Tabel ini menunjukkan perbedaan utama dengan masing-masing strategi.