Merencanakan Strategi Akun Multi Beban Kerja untuk Multi Tenant Cluster Kluster EKS Terpusat Cluster EKS yang tidak terpusat Cluster EKS terpusat vs de-sentralisasi

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:

Peningkatan kuota layanan AWS API. Kuota diterapkan ke akun AWS, dan menggunakan beberapa akun untuk beban kerja Anda meningkatkan keseluruhan kuota yang tersedia untuk beban kerja Anda.
Kebijakan Identity and Access Management (IAM) yang lebih sederhana Memberikan beban kerja dan operator yang mendukung mereka akses hanya ke akun AWS mereka sendiri berarti lebih sedikit waktu menyusun kebijakan IAM berbutir halus untuk mencapai prinsip hak istimewa yang paling rendah.
Peningkatan Isolasi sumber daya AWS. Secara desain, semua sumber daya yang disediakan dalam akun secara logis diisolasi dari sumber daya yang disediakan di akun lain. Batas isolasi ini memberi Anda cara untuk membatasi risiko masalah terkait aplikasi, kesalahan konfigurasi, atau tindakan jahat. Jika masalah terjadi dalam satu akun, dampak terhadap beban kerja yang terdapat di akun lain dapat dikurangi atau dihilangkan.
Manfaat lainnya, seperti yang dijelaskan dalam Whitepaper Strategi Multi Akun AWS

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, cluster EKS, sumber daya komputasi EC2 /Fargate (node pekerja), dan konfigurasi jaringan tambahan apa pun yang diperlukan untuk menjalankan cluster 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 Sumber Daya Berbagi Anda dan Pilih subnet yang ingin Anda bagikan. Pilih Berikutnya lagi dan masukkan akun 12 digit IDs 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 kredensil AWS sementara ke pod Anda di EKS. Identitas Pod IRSA dan EKS adalah metode yang valid untuk mengirimkan kredensil 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 kredensyal 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 adalah cara baru untuk mengirimkan kredensyal AWS ke beban kerja Anda yang berjalan di EKS. Identitas pod EKS menyederhanakan konfigurasi sumber daya AWS karena Anda tidak perlu lagi mengelola konfigurasi OIDC untuk mengirimkan kredensyal AWS ke pod Anda di EKS.

Mengaktifkan Identitas Pod EKS untuk akses lintas akun

Tidak seperti IRSA, EKS Pod Identities hanya dapat digunakan untuk secara langsung memberikan akses ke peran dalam akun yang sama dengan cluster EKS. Untuk mengakses peran di akun AWS lain, pod yang menggunakan Identitas Pod EKS harus melakukan Role Chaining.

Role chaining dapat dikonfigurasi dalam profil aplikasi dengan file konfigurasi awsnya menggunakan Penyedia Kredensial Proses yang tersedia di berbagai AWS. SDKs credential_processdapat digunakan sebagai sumber kredensi saat mengonfigurasi profil, seperti:


# Content of the AWS Config file
[profile account_b_role]
source_profile = account_a_role
role_arn = arn:aws:iam::444455556666:role/account-b-role

[profile account_a_role]
credential_process = /eks-credential-processrole.sh

Sumber skrip yang disebut oleh credential_process:


#!/bin/bash
# Content of the eks-credential-processrole.sh
# This will retreive the credential from the pod identities agent,
# and return it to the AWS SDK when referenced in a profile
curl -H "Authorization: $(cat $AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE)" $AWS_CONTAINER_CREDENTIALS_FULL_URI | jq -c '{AccessKeyId: .AccessKeyId, SecretAccessKey: .SecretAccessKey, SessionToken: .Token, Expiration: .Expiration, Version: 1}'

Anda dapat membuat file konfigurasi aws seperti yang ditunjukkan di atas dengan peran Akun A dan B dan menentukan vars AWS_CONFIG_FILE dan AWS_PROFILE env dalam spesifikasi pod Anda. EKS Pod identity webhook tidak diganti jika env vars sudah ada dalam spesifikasi pod.


# Snippet of the PodSpec
containers:
  - name: container-name
    image: container-image:version
    env:
    - name: AWS_CONFIG_FILE
      value: path-to-customer-provided-aws-config-file
    - name: AWS_PROFILE
      value: account_b_role

Saat mengonfigurasi kebijakan kepercayaan peran untuk rantai peran dengan identitas pod EKS, Anda dapat mereferensikan atribut khusus EKS sebagai tag sesi dan menggunakan kontrol akses berbasis atribut (ABAC) untuk membatasi akses ke peran IAM Anda hanya pada sesi identitas EKS Pod tertentu, seperti Akun Layanan Kubernetes yang dimiliki pod.

Harap dicatat bahwa beberapa atribut ini mungkin tidak unik secara universal, misalnya dua kluster EKS mungkin memiliki ruang nama yang identik, dan satu cluster mungkin memiliki akun layanan bernama identik di seluruh ruang nama. Jadi ketika memberikan akses melalui EKS Pod Identities dan ABAC, itu adalah praktik terbaik untuk selalu mempertimbangkan cluster arn dan namespace saat memberikan akses ke akun layanan.

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 memungkinkan peran diasumsikan oleh sesi peran ketika nilai yang diharapkan ada. Kebijakan kepercayaan peran berikut hanya akan membiarkan peran dari akun klaster EKS (ID akun 111122223333) 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:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalTag/kubernetes-service-account": "PayrollApplication",
                    "aws:PrincipalTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/ProductionCluster",
                    "aws:PrincipalTag/kubernetes-namespace": "PayrollNamespace"
                }
            }
        }
    ]
}

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

Penting saat menggunakan ABAC bahwa Anda mengontrol siapa yang memiliki kemampuan untuk menandai peran IAM dan pengguna hanya kepada mereka yang memiliki kebutuhan ketat untuk melakukannya. Seseorang dengan kemampuan untuk menandai peran IAM atau pengguna akan dapat mengatur tag yang roles/users identik dengan apa yang akan ditetapkan oleh EKS Pod Identities dan mungkin dapat meningkatkan hak istimewa mereka. Anda dapat membatasi siapa yang memiliki akses untuk menyetel tag kubernetes- dan eks- tag pada peran IAM dan pengguna menggunakan kebijakan IAM, atau Kebijakan Kontrol Layanan (SCP).

Cluster EKS yang tidak terpusat

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, VPCs, tabel Amazon DynamoDB, dll., Setiap akun beban kerja independen, mandiri, dan dioperasikan oleh masing-masing klaster Unit/Application teams. This model allows the creation of reusuable blueprints for various cluster capabilities — AI/ML Bisnis, Pemrosesan Batch, Tujuan umum, dll, — dan menjual klaster berdasarkan persyaratan tim aplikasi. Baik tim aplikasi dan platform beroperasi dari GitOpsrepositori masing-masing untuk mengelola penerapan ke cluster beban kerja.

Arsitektur Kluster EKS yang tidak terpusat

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 manajemen/administrasi jaringan terpusat, konektivitas jaringan yang disederhanakan, dan kluster EKS yang tidak terpusat. Lihat blog AWS ini untuk panduan dan pertimbangan terperinci tentang pendekatan ini.

Arsitektur Kluster EKS yang tidak terpusat menggunakan Subnet Bersama VPC

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 EKS terpusat vs de-sentralisasi

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

#	Kluster EKS terpusat	Cluster EKS yang tidak terpusat
Manajemen Cluster:	Mengelola satu kluster EKS lebih mudah daripada mengelola beberapa cluster	Otomatisasi manajemen cluster yang efisien diperlukan untuk mengurangi overhead operasional pengelolaan beberapa kluster EKS
Efisiensi Biaya:	Memungkinkan penggunaan kembali cluster EKS dan sumber daya jaringan, yang mempromosikan efisiensi biaya	Membutuhkan pengaturan jaringan dan cluster per beban kerja, yang membutuhkan sumber daya tambahan
Ketahanan:	Beberapa beban kerja pada cluster terpusat dapat terpengaruh jika klaster menjadi terganggu	Jika cluster menjadi terganggu, kerusakan terbatas hanya pada beban kerja yang berjalan di cluster itu. Semua beban kerja lainnya tidak terpengaruh
Isolasi & Keamanan:	Isolasi/Soft Multi-tenancy dicapai dengan menggunakan konstruksi asli k8s seperti. `Namespaces` Beban kerja dapat berbagi sumber daya yang mendasarinya seperti CPU, memori, dll. Sumber daya AWS diisolasi ke dalam akun beban kerjanya sendiri yang secara default tidak dapat diakses dari akun AWS lainnya.	Isolasi yang lebih kuat pada sumber daya komputasi karena beban kerja berjalan di masing-masing cluster dan node yang tidak berbagi sumber daya apa pun. Sumber daya AWS diisolasi ke dalam akun beban kerjanya sendiri yang secara default tidak dapat diakses dari akun AWS lainnya.
Kinerja & Skalabitas:	Saat beban kerja bertambah menjadi skala yang sangat besar, Anda mungkin menemukan kubernetes dan kuota layanan AWS di akun klaster. Anda dapat menerapkan akun klaster tambahan untuk menskalakan lebih jauh	Semakin banyak cluster dan VPCs hadir, setiap beban kerja memiliki lebih banyak kuota layanan k8 dan AWS yang tersedia
Jaringan:	VPC tunggal digunakan per cluster, memungkinkan konektivitas yang lebih sederhana untuk aplikasi di cluster itu	Perutean harus dibuat antara kluster EKS yang tidak terpusat VPCs
Manajemen Akses Kubernetes:	Perlu mempertahankan banyak peran dan pengguna yang berbeda di klaster untuk menyediakan akses ke semua tim beban kerja dan memastikan sumber daya kubernetes dipisahkan dengan benar	Manajemen akses yang disederhanakan karena setiap cluster didedikasikan untuk beban kerja/tim
Manajemen Akses AWS:	Sumber daya AWS diterapkan ke akun mereka sendiri yang hanya dapat diakses secara default dengan peran IAM di akun beban kerja. Peran IAM dalam akun beban kerja diasumsikan lintas akun baik dengan IRSA atau EKS Pod Identities.	Sumber daya AWS diterapkan ke akun mereka sendiri yang hanya dapat diakses secara default dengan peran IAM di akun beban kerja. Peran IAM dalam akun beban kerja dikirim langsung ke pod dengan IRSA atau EKS Pod Identities

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Keamanan gambar

Manajemen akses cluster