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

Identity and Access Management

Identity and Access Management (IAM) adalah layanan AWS yang melakukan dua fungsi penting: Otentikasi dan Otorisasi. Otentikasi melibatkan verifikasi identitas sedangkan otorisasi mengatur tindakan yang dapat dilakukan oleh sumber daya AWS. Dalam AWS, sumber daya dapat berupa layanan AWS lain, misalnya EC2, atau prinsipal AWS https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html#intro-structure-principal seperti Pengguna atau Peran IAM. Aturan yang mengatur tindakan yang diizinkan untuk dilakukan sumber daya dinyatakan sebagai kebijakan https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html IAM.

Mengontrol Akses ke Cluster EKS

Proyek Kubernetes mendukung berbagai strategi berbeda untuk mengotentikasi permintaan ke layanan kube-apiserver, misalnya Token Pembawa, sertifikat, OIDC, dll. X.509 EKS saat ini memiliki dukungan asli untuk otentikasi token webhook, token akun layanan, dan per 21 Februari 2021, otentikasi OIDC.

Strategi otentikasi webhook memanggil webhook yang memverifikasi token pembawa. Di EKS, token pembawa ini dihasilkan oleh AWS CLI atau klien aws-iam-authentic ator saat Anda menjalankan perintah. kubectl Saat Anda menjalankan perintah, token diteruskan ke kube-apiserver yang meneruskannya ke webhook otentikasi. Jika permintaan terbentuk dengan baik, webhook memanggil URL yang telah ditandatangani sebelumnya yang disematkan di tubuh token. URL ini memvalidasi tanda tangan permintaan dan mengembalikan informasi tentang pengguna, misalnya akun pengguna, Arn, dan UserId ke kube-apiserver.

Untuk membuat token otentikasi secara manual, ketik perintah berikut di jendela terminal:

aws eks get-token --cluster-name <cluster_name> --region <region>

Outputnya harus menyerupai ini:

{
    "kind": "ExecCredential",
    "apiVersion": "client.authentication.k8s.io/v1alpha1",
    "spec": {},
    "status": {
        "expirationTimestamp": "2024-12-20T17:38:48Z",
        "token": "k8s-aws-v1.aHR0cHM6Ly9zdHMudXMtd2VzdC0yLmFtYXpvbmF3cy5jb20vP0FjdGlvbj1HZ...."
    }
}

Anda juga bisa mendapatkan token secara terprogram. Di bawah ini adalah contoh yang ditulis dalam Go:

package main

import (
  "fmt"
  "log"
  "sigs.k8s.io/aws-iam-authenticator/pkg/token"
)

func main()  {
  g, _ := token.NewGenerator(false, false)
  tk, err := g.Get("<cluster_name>")
  if err != nil {
    log.Fatal(err)
  }
  fmt.Println(tk)
}

Outputnya harus menyerupai ini:

{
  "kind": "ExecCredential",
  "apiVersion": "client.authentication.k8s.io/v1alpha1",
  "spec": {},
  "status": {
    "expirationTimestamp": "2020-02-19T16:08:27Z",
    "token": "k8s-aws-v1.aHR0cHM6Ly9zdHMuYW1hem9uYXdzLmNvbS8_QWN0aW9uPUdldENhbGxlcklkZW50aXR5JlZlcnNpb249MjAxMS0wNi0xNSZYLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFKTkdSSUxLTlNSQzJXNVFBJTJGMjAyMDAyMTklMkZ1cy1lYXN0LTElMkZzdHMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDIwMDIxOVQxNTU0MjdaJlgtQW16LUV4cGlyZXM9NjAmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JTNCeC1rOHMtYXdzLWlkJlgtQW16LVNpZ25hdHVyZT0yMjBmOGYzNTg1ZTMyMGRkYjVlNjgzYTVjOWE0MDUzMDFhZDc2NTQ2ZjI0ZjI4MTExZmRhZDA5Y2Y2NDhhMzkz"
  }
}

Setiap token dimulai dengan k8s-aws-v1. diikuti oleh string yang dikodekan base64. String, ketika diterjemahkan, harus menyerupai sesuatu yang mirip dengan ini:

https://sts.amazonaws.com/?Action=GetCallerIdentity&Version=2011-06-15&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=XXXXJPFRILKNSRC2W5QA%2F20200219%2Fus-xxxx-1%2Fsts%2Faws4_request&X-Amz-Date=20200219T155427Z&X-Amz-Expires=60&X-Amz-SignedHeaders=host%3Bx-k8s-aws-id&X-Amz-Signature=XXXf8f3285e320ddb5e683a5c9a405301ad76546f24f28111fdad09cf648a393

Token terdiri dari URL yang telah ditandatangani sebelumnya yang menyertakan kredensi dan tanda tangan Amazon. Untuk detail lebih lanjut lihat https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html.

Token memiliki waktu hidup (TTL) 15 menit setelah itu token baru perlu dibuat. Ini ditangani secara otomatis ketika Anda menggunakan klien sepertikubectl, namun, jika Anda menggunakan dasbor Kubernetes, Anda harus membuat token baru dan mengautentikasi ulang setiap kali token kedaluwarsa.

Setelah identitas pengguna diautentikasi oleh layanan AWS IAM, kube-apiserver membaca aws-auth ConfigMap di kube-system Namespace untuk menentukan grup RBAC yang akan diasosiasikan dengan pengguna. Ini aws-auth ConfigMap digunakan untuk membuat pemetaan statis antara prinsipal IAM, yaitu Pengguna dan Peran IAM, dan grup RBAC Kubernetes. Grup RBAC dapat direferensikan di Kuber RoleBindings netes atau. ClusterRoleBindings Mereka mirip dengan Peran IAM karena mereka mendefinisikan serangkaian tindakan (kata kerja) yang dapat dilakukan terhadap kumpulan sumber daya Kubernetes (objek).

CloudWatch query untuk membantu pengguna mengidentifikasi klien yang mengirim permintaan ke titik akhir STS global

Jalan CloudWatch kan kueri di bawah ini untuk mendapatkan titik akhir sts. Jika stsendpoint sama dengan “sts.amazonaws.com”, maka itu adalah titik akhir STS global. Jika stsendpoint sama dengan “sts. <region>.amazonaws.com”, maka itu adalah titik akhir STS regional.

fields @timestamp, @message, @logStream, @log,stsendpoint
| filter @logStream like /authenticator/
| filter @message like /stsendpoint/
| sort @timestamp desc
| limit 10000

Manajer Akses Cluster

Cluster Access Manager, sekarang cara yang lebih disukai untuk mengelola akses prinsipal AWS IAM ke cluster Amazon EKS, adalah fungsionalitas AWS API dan merupakan fitur opt-in untuk EKS v1.23 dan cluster yang lebih baru (baru atau yang sudah ada). Ini menyederhanakan pemetaan identitas antara AWS IAM dan Kubernetes RBAC, menghilangkan kebutuhan untuk beralih antara AWS dan API Kubernetes atau mengedit aws-auth ConfigMap untuk manajemen akses, mengurangi overhead operasional, dan membantu mengatasi kesalahan konfigurasi. Alat ini juga memungkinkan administrator cluster untuk mencabut atau memperbaiki cluster-admin izin yang secara otomatis diberikan kepada prinsipal AWS IAM yang digunakan untuk membuat cluster.

API ini bergantung pada dua konsep:

Saat diluncurkan, Amazon EKS hanya mendukung kebijakan yang telah ditentukan sebelumnya dan dikelola AWS. Kebijakan akses bukan entitas IAM dan ditentukan dan dikelola oleh Amazon EKS.

Cluster Access Manager memungkinkan kombinasi RBAC hulu dengan Kebijakan Akses yang mendukung izinkan dan meneruskan (tetapi tidak menolak) pada keputusan Kubernetes AuthZ mengenai permintaan server API. Keputusan penolakan akan terjadi ketika keduanya, otorisasi RBAC hulu dan Amazon EKS tidak dapat menentukan hasil evaluasi permintaan.

Dengan fitur ini, Amazon EKS mendukung tiga mode otentikasi:

Untuk memulai, administrator cluster dapat membuat atau memperbarui cluster Amazon EKS, mengatur otentikasi API_AND_CONFIG_MAP atau API metode yang disukai dan menentukan Entri Akses untuk memberikan akses prinsipal AWS IAM yang diinginkan.

$ aws eks create-cluster \
    --name <CLUSTER_NAME> \
    --role-arn <CLUSTER_ROLE_ARN> \
    --resources-vpc-config subnetIds=<value>,endpointPublicAccess=true,endpointPrivateAccess=true \
    --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}' \
    --access-config authenticationMode=API_AND_CONFIG_MAP,bootstrapClusterCreatorAdminPermissions=false

Perintah di atas adalah contoh untuk membuat cluster Amazon EKS tanpa izin admin dari pembuat cluster.

Dimungkinkan untuk memperbarui konfigurasi cluster Amazon EKS untuk mengaktifkan API AuthenticationMode menggunakan update-cluster-config perintah, untuk melakukannya pada cluster yang ada menggunakan CONFIG_MAP Anda harus terlebih dahulu memperbarui ke API_AND_CONFIG_MAP dan kemudian ke. API Operasi ini tidak dapat dikembalikan, artinya tidak mungkin untuk beralih dari API ke API_AND_CONFIG_MAP atauCONFIG_MAP, dan juga dari API_AND_CONFIG_MAP keCONFIG_MAP.

$ aws eks update-cluster-config \
    --name <CLUSTER_NAME> \
    --access-config authenticationMode=API

API mendukung perintah untuk menambah dan mencabut akses ke cluster, serta memvalidasi Kebijakan Akses dan Entri Akses yang ada untuk cluster yang ditentukan. Kebijakan default dibuat untuk mencocokkan Kubernetes RBAC sebagai berikut.

$ aws eks list-access-policies
{
    "accessPolicies": [
        {
            "name": "AmazonEKSAdminPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy"
        },
        {
            "name": "AmazonEKSClusterAdminPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
        },
        {
            "name": "AmazonEKSEditPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy"
        },
        {
            "name": "AmazonEKSViewPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy"
        }
    ]
}

$ aws eks list-access-entries --cluster-name <CLUSTER_NAME>

{
    "accessEntries": []
}

Tidak ada Entri Akses yang tersedia saat cluster dibuat tanpa izin admin pembuat cluster, yang merupakan satu-satunya entri yang dibuat secara default.

Aws-auth ConfigMap (tidak digunakan lagi)

Salah satu cara integrasi Kubernetes dengan otentikasi AWS dapat dilakukan adalah melalui aws-auth ConfigMap, yang berada di Namespace. kube-system Ini bertanggung jawab untuk memetakan otentikasi AWS IAM Identities (Users, Groups, and Roles), ke otorisasi kontrol akses berbasis peran (RBAC) Kubernetes. Secara otomatis aws-auth ConfigMap dibuat di cluster Amazon EKS Anda selama fase penyediaannya. Ini awalnya dibuat untuk memungkinkan node bergabung dengan cluster Anda, tetapi seperti yang disebutkan Anda juga dapat menggunakan ini ConfigMap untuk menambahkan akses RBAC ke prinsipal IAM.

Untuk memeriksa cluster Anda aws-auth ConfigMap, Anda dapat menggunakan perintah berikut.

kubectl -n kube-system get configmap aws-auth -o yaml

Ini adalah contoh konfigurasi default dari aws-authConfigMap.

apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      - system:node-proxier
      rolearn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/kube-system-<SELF_GENERATED_UUID>
      username: system:node:{{SessionName}}
kind: ConfigMap
metadata:
  creationTimestamp: "2023-10-22T18:19:30Z"
  name: aws-auth
  namespace: kube-system

Sesi utama ini ConfigMap, ada data di bawah mapRoles blok, yang pada dasarnya disusun oleh 3 parameter.

Dimungkinkan juga untuk memetakan izin untuk Pengguna AWS IAM, mendefinisikan blok konfigurasi baru untukmapUsers, data di bawah aws-authConfigMap, mengganti parameter rolearn untuk userarn, namun sebagai Prakti k Terbaik, selalu disarankan kepada pengguna sebagai gantinya. mapRoles

Untuk mengelola izin, Anda dapat mengedit aws-auth ConfigMap penambahan atau penghapusan akses ke cluster Amazon EKS Anda. Meskipun dimungkinkan untuk mengedit secara aws-auth ConfigMap manual, disarankan menggunakan alat sepertieksctl, karena ini adalah konfigurasi yang sangat sensitif, dan konfigurasi yang tidak akurat dapat mengunci Anda di luar Amazon EKS Cluster Anda. Periksa subbagian Gunakan alat untuk membuat perubahan pada aws-auth ConfigMap di bawah ini untuk detail lebih lanjut.

Manfaat dibandingkan manajemen ConfigMap-based akses

Rekomendasi Akses Cluster

Gabungkan Pusat Identitas IAM dengan API CAM

Jadikan Endpoint Cluster EKS menjadi pribadi

Secara default saat Anda menyediakan cluster EKS, titik akhir cluster API disetel ke publik, yaitu dapat diakses dari Internet. Meskipun dapat diakses dari Internet, titik akhir masih dianggap aman karena memerlukan semua permintaan API untuk diautentikasi oleh IAM dan kemudian disahkan oleh Kubernetes RBAC. Meskipun demikian, jika kebijakan keamanan perusahaan Anda mengamanatkan bahwa Anda membatasi akses ke API dari Internet atau mencegah Anda merutekan lalu lintas di luar VPC cluster, Anda dapat:

Jangan gunakan token akun layanan untuk otentikasi

Token akun layanan adalah kredensi statis yang berumur panjang. Jika dikompromikan, hilang, atau dicuri, penyerang mungkin dapat melakukan semua tindakan yang terkait dengan token tersebut hingga akun layanan dihapus. Kadang-kadang, Anda mungkin perlu memberikan pengecualian untuk aplikasi yang harus menggunakan API Kubernetes dari luar cluster, misalnya aplikasi pipeline. CI/CD Jika aplikasi tersebut berjalan pada infrastruktur AWS, seperti instans EC2, pertimbangkan untuk menggunakan profil instans dan memetakannya ke peran Kubernetes RBAC.

Gunakan akses yang paling tidak memiliki hak istimewa ke Sumber Daya AWS

Pengguna IAM tidak perlu diberi hak istimewa ke sumber daya AWS untuk mengakses API Kubernetes. Jika Anda perlu memberikan akses pengguna IAM ke cluster EKS, buat entri aws-auth ConfigMap untuk pengguna tersebut yang memetakan ke grup RBAC Kubernetes tertentu.

Hapus izin cluster-admin dari prinsipal pembuat cluster

Secara default, cluster Amazon EKS dibuat dengan cluster-admin izin permanen yang terikat ke prinsipal pembuat cluster. Dengan API Manajer Akses Cluster, Anda dapat membuat cluster tanpa izin ini menyetel mode --access-config bootstrapClusterCreatorAdminPermissions kefalse, saat menggunakan, API_AND_CONFIG_MAP atau API otentikasi. Cabut akses ini dianggap sebagai praktik terbaik untuk menghindari perubahan yang tidak diinginkan pada konfigurasi cluster. Proses untuk mencabut akses ini, mengikuti proses yang sama untuk mencabut akses lain ke cluster.

API memberi Anda fleksibilitas untuk hanya memisahkan prinsipal IAM dari Kebijakan Akses, dalam hal ini. AmazonEKSClusterAdminPolicy

$ aws eks list-associated-access-policies \
    --cluster-name <CLUSTER_NAME> \
    --principal-arn <IAM_PRINCIPAL_ARN>

$ aws eks disassociate-access-policy --cluster-name <CLUSTER_NAME> \
    --principal-arn <IAM_PRINCIPAL_ARN. \
    --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy

Atau sepenuhnya menghapus Entri Akses yang terkait dengan cluster-admin izin.

$ aws eks list-access-entries --cluster-name <CLUSTER_NAME>

{
    "accessEntries": []
}

$ aws eks delete-access-entry --cluster-name <CLUSTER_NAME> \
  --principal-arn <IAM_PRINCIPAL_ARN>

Akses ini dapat diberikan lagi jika diperlukan selama insiden, keadaan darurat atau skenario pecahan kaca di mana cluster tidak dapat diakses.

Jika cluster masih dikonfigurasi dengan metode CONFIG_MAP otentikasi, semua pengguna tambahan harus diberikan akses ke cluster melalui aws-auth ConfigMap, dan setelah aws-auth ConfigMap dikonfigurasi, peran yang ditetapkan ke entitas yang membuat cluster, dapat dihapus dan hanya dibuat ulang jika terjadi insiden, skenario darurat atau pecahan kaca, atau di mana klaster aws-auth ConfigMap rusak dan cluster tidak dapat diakses. Hal ini dapat sangat berguna dalam klaster produksi.

Gunakan Peran IAM ketika beberapa pengguna memerlukan akses yang identik ke cluster

Alih-alih membuat entri untuk setiap Pengguna IAM individu, izinkan pengguna tersebut mengambil Peran IAM dan memetakan peran itu ke grup RBAC Kubernetes. Ini akan lebih mudah untuk dipertahankan, terutama karena jumlah pengguna yang membutuhkan akses bertambah.

Jika masih menggunakan aws-auth ConfigMap sebagai metode otentikasi, saat menetapkan izin RBAC K8s ke peran IAM, Anda harus menyertakan\ {{SessionName}} dalam nama pengguna Anda. Dengan begitu, log audit akan merekam nama sesi sehingga Anda dapat melacak siapa pengguna sebenarnya yang mengambil peran ini bersama dengan CloudTrail log.

- rolearn: arn:aws:iam::XXXXXXXXXXXX:role/testRole
  username: testRole:{{SessionName}}
  groups:
    - system:masters

Gunakan akses yang paling tidak memiliki hak istimewa saat membuat RoleBindings dan ClusterRoleBindings

Seperti poin sebelumnya tentang pemberian akses ke Sumber Daya AWS, RoleBindings dan ClusterRoleBindings seharusnya hanya menyertakan kumpulan izin yang diperlukan untuk melakukan fungsi tertentu. Hindari menggunakan ["*"] dalam Peran Anda dan ClusterRoles kecuali itu benar-benar diperlukan. Jika Anda tidak yakin izin apa yang harus ditetapkan, pertimbangkan untuk menggunakan alat seperti audit2rbac untuk secara otomatis menghasilkan Peran dan pengikatan berdasarkan panggilan API yang diamati di Log Audit Kubernetes.

Buat cluster menggunakan proses otomatis

Seperti yang terlihat pada langkah sebelumnya, saat membuat cluster Amazon EKS, jika tidak menggunakan mode penggunaan API_AND_CONFIG_MAP atau API otentikasi, dan tidak memilih keluar untuk mendelegasikan cluster-admin izin kepada pembuat cluster, pengguna atau peran entitas IAM, seperti pengguna federasi yang membuat cluster, secara otomatis diberikan system:masters izin dalam konfigurasi RBAC cluster. Bahkan menjadi praktik terbaik untuk menghapus izin ini, seperti yang dijelaskan di sini jika menggunakan metode CONFIG_MAP otentikasi, mengandalkan aws-auth ConfigMap, akses ini tidak dapat dicabut. Oleh karena itu, adalah ide yang baik untuk membuat cluster dengan pipeline otomatisasi infrastruktur yang terkait dengan peran IAM khusus, tanpa izin yang harus diasumsikan oleh pengguna atau entitas lain dan secara teratur mengaudit izin peran ini, kebijakan, dan siapa yang memiliki akses untuk memicu pipeline. Selain itu, peran ini tidak boleh digunakan untuk melakukan tindakan rutin pada cluster, dan secara eksklusif digunakan untuk tindakan tingkat cluster yang dipicu oleh pipeline, melalui perubahan kode SCM misalnya.

Buat cluster dengan peran IAM khusus

Saat Anda membuat cluster Amazon EKS, pengguna atau peran entitas IAM, seperti pengguna federasi yang membuat cluster, secara otomatis diberikan system:masters izin dalam konfigurasi RBAC cluster. Akses ini tidak dapat dihapus dan tidak dikelola melalui aws-auth ConfigMap. Oleh karena itu adalah ide yang baik untuk membuat cluster dengan peran IAM khusus dan secara teratur mengaudit siapa yang dapat mengambil peran ini. Peran ini tidak boleh digunakan untuk melakukan tindakan rutin pada cluster, dan sebagai gantinya pengguna tambahan harus diberikan akses ke cluster melalui aws-auth ConfigMap untuk tujuan ini. Setelah aws-auth ConfigMap dikonfigurasi, peran harus diamankan dan hanya digunakan dalam mode hak istimewa yang ditinggikan sementara/memecahkan kaca untuk skenario di mana cluster tidak dapat diakses. Ini bisa sangat berguna dalam cluster yang tidak memiliki akses pengguna langsung yang dikonfigurasi.

Secara teratur mengaudit akses ke cluster

Siapa yang membutuhkan akses kemungkinan akan berubah seiring waktu. Rencanakan untuk mengaudit secara berkala aws-auth ConfigMap untuk melihat siapa yang telah diberikan akses dan hak yang telah diberikan kepada mereka. Anda juga dapat menggunakan alat sumber terbuka seperti kubectl-who-can, atau rbac-lookup untuk memeriksa peran yang terikat ke akun layanan tertentu, pengguna, atau grup. Kita akan mengeksplorasi topik ini lebih lanjut ketika kita sampai ke bagian tentang audit. Ide tambahan dapat ditemukan di artikel ini dari NCC Group.

Jika mengandalkan aws-auth ConfigMap gunakan alat untuk membuat perubahan

Aws-auth yang diformat secara tidak benar ConfigMap dapat menyebabkan Anda kehilangan akses ke cluster. Jika Anda perlu membuat perubahan pada ConfigMap, gunakan alat.

eksctl eksctl CLI menyertakan perintah untuk menambahkan pemetaan identitas ke aws-auth. ConfigMap

Lihat Bantuan CLI:

$ eksctl create iamidentitymapping --help
...

Periksa identitas yang dipetakan ke Amazon EKS Cluster Anda.

$ eksctl get iamidentitymapping --cluster $CLUSTER_NAME --region $AWS_REGION
ARN                                                                   USERNAME                        GROUPS                                                  ACCOUNT
arn:aws:iam::788355785855:role/kube-system-<SELF_GENERATED_UUID>      system:node:{{SessionName}}     system:bootstrappers,system:nodes,system:node-proxier

Jadikan Peran IAM sebagai Admin Cluster:

$ eksctl create iamidentitymapping --cluster  <CLUSTER_NAME> --region=<region> --arn arn:aws:iam::123456:role/testing --group system:masters --username admin
...

Untuk informasi selengkapnya, tinjau eksctl dokumen

aws-aut h oleh keikoproj

aws-autholeh keikoproj mencakup perpustakaan cli dan go.

Unduh dan lihat bantuan CLI bantuan:

$ go get github.com/keikoproj/aws-auth
...
$ aws-auth help
...

Atau, instal aws-auth dengan manajer plugin krew untuk kubectl.

$ kubectl krew install aws-auth
...
$ kubectl aws-auth
...

Tinjau dokumen aws-auth GitHub untuk informasi lebih lanjut, termasuk perpustakaan go.

AWS IAM Authenticator CLI

aws-iam-authenticatorProyek ini mencakup CLI untuk memperbarui. ConfigMap

Unduh rilis di GitHub.

Tambahkan izin cluster ke Peran IAM:

$ ./aws-iam-authenticator add role --rolearn arn:aws:iam::185309785115:role/lil-dev-role-cluster --username lil-dev-user --groups system:masters --kubeconfig ~/.kube/config
...

Pendekatan Alternatif untuk Otentikasi dan Manajemen Akses

Meskipun IAM adalah cara yang lebih disukai untuk mengotentikasi pengguna yang membutuhkan akses ke cluster EKS, dimungkinkan untuk menggunakan penyedia identitas OIDC seperti GitHub menggunakan proxy otentikasi dan peniruan Kubernetes. https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation Posting untuk dua solusi tersebut telah dipublikasikan di blog AWS Open Source:

Anda juga dapat menggunakan AWS SSO untuk menyatukan AWS dengan penyedia identitas eksternal, misalnya Azure AD. Jika Anda memutuskan untuk menggunakan ini, AWS CLI v2.0 menyertakan opsi untuk membuat profil bernama yang memudahkan untuk mengaitkan sesi SSO dengan sesi CLI Anda saat ini dan mengambil peran IAM. Ketahuilah bahwa Anda harus mengambil peran sebelum menjalankan kubectl karena peran IAM digunakan untuk menentukan grup RBAC Kubernetes pengguna.

Identitas dan Kredentif untuk pod EKS

Aplikasi tertentu yang berjalan dalam cluster Kubernetes memerlukan izin untuk memanggil API Kubernetes agar berfungsi dengan baik. Misalnya, AWS Load Balancer Controller harus dapat membuat daftar Titik Akhir Layanan. Pengontrol juga harus dapat memanggil AWS API untuk menyediakan dan mengonfigurasi ALB. Pada bagian ini kita akan mengeksplorasi praktik terbaik untuk menetapkan hak dan hak istimewa ke Pod.

Akun Layanan Kubernetes

Akun layanan adalah jenis objek khusus yang memungkinkan Anda menetapkan peran Kubernetes RBAC ke pod. Akun layanan default dibuat secara otomatis untuk setiap Namespace dalam cluster. Saat Anda menyebarkan pod ke Namespace tanpa mereferensikan akun layanan tertentu, akun layanan default untuk Namespace tersebut akan secara otomatis ditetapkan ke Pod dan Rahasia, yaitu token akun layanan (JWT) untuk akun layanan itu, akan dipasang ke pod sebagai volume di. /var/run/secrets/kubernetes.io/serviceaccount Mendekode token akun layanan di direktori itu akan mengungkapkan metadata berikut:

{
  "iss": "kubernetes/serviceaccount",
  "kubernetes.io/serviceaccount/namespace": "default",
  "kubernetes.io/serviceaccount/secret.name": "default-token-5pv4z",
  "kubernetes.io/serviceaccount/service-account.name": "default",
  "kubernetes.io/serviceaccount/service-account.uid": "3b36ddb5-438c-11ea-9438-063a49b60fba",
  "sub": "system:serviceaccount:default:default"
}

Akun layanan default memiliki izin berikut ke API Kubernetes.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2020-01-30T18:13:25Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:discovery
  resourceVersion: "43"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/system%3Adiscovery
  uid: 350d2ab8-438c-11ea-9438-063a49b60fba
rules:
- nonResourceURLs:
  - /api
  - /api/*
  - /apis
  - /apis/*
  - /healthz
  - /openapi
  - /openapi/*
  - /version
  - /version/
  verbs:
  - get

Peran ini mengizinkan pengguna yang tidak diautentikasi dan diautentikasi untuk membaca informasi API dan dianggap aman untuk dapat diakses publik.

Ketika aplikasi yang berjalan di dalam Pod memanggil API Kubernetes, Pod perlu diberi akun layanan yang secara eksplisit memberinya izin untuk memanggil API tersebut. Mirip dengan pedoman untuk akses pengguna, Per ClusterRole an atau terikat ke akun layanan harus dibatasi pada sumber daya API dan metode yang diperlukan aplikasi untuk berfungsi dan tidak ada yang lain. Untuk menggunakan akun layanan non-default, cukup spec.serviceAccountName atur bidang Pod ke nama akun layanan yang ingin Anda gunakan. Untuk informasi tambahan tentang membuat akun layanan, lihat https://kubernetes.io/docs/reference/access-authn-authz/rbac/ #service -account-permissions.

Peran IAM untuk Akun Layanan (IRSA)

IRSA adalah fitur yang memungkinkan Anda menetapkan peran IAM ke akun layanan Kubernetes. Ini bekerja dengan memanfaatkan fitur Kubernetes yang dikenal sebagai Proyeksi Volume Token Akun Layanan. Ketika Pod dikonfigurasi dengan Akun Layanan yang mereferensikan Peran IAM, server API Kubernetes akan memanggil titik akhir penemuan OIDC publik untuk cluster saat startup. Titik akhir secara kriptografis menandatangani token OIDC yang dikeluarkan oleh Kubernetes dan token yang dihasilkan dipasang sebagai volume. Token yang ditandatangani ini memungkinkan Pod memanggil peran IAM terkait AWS API. Saat AWS API dipanggil, AWS SDK akan memanggil. sts:AssumeRoleWithWebIdentity Setelah memvalidasi tanda tangan token, IAM menukar token yang dikeluarkan Kubernetes dengan kredenSIAL peran AWS sementara.

Saat menggunakan IRSA, penting untuk menggunakan kembali sesi Gunakan kembali sesi AWS SDK dengan IRSA AWS SDK untuk menghindari panggilan yang tidak perlu ke AWS STS.

Mendekode token (JWT) untuk IRSA akan menghasilkan output yang mirip dengan contoh yang Anda lihat di bawah ini:

{
  "aud": [
    "sts.amazonaws.com"
  ],
  "exp": 1582306514,
  "iat": 1582220114,
  "iss": "https://oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128",
  "kubernetes.io": {
    "namespace": "default",
    "pod": {
      "name": "alpine-57b5664646-rf966",
      "uid": "5a20f883-5407-11ea-a85c-0e62b7a4a436"
    },
    "serviceaccount": {
      "name": "s3-read-only",
      "uid": "a720ba5c-5406-11ea-9438-063a49b60fba"
    }
  },
  "nbf": 1582220114,
  "sub": "system:serviceaccount:default:s3-read-only"
}

Token khusus ini memberikan hak istimewa khusus tampilan Pod ke S3 dengan mengambil peran IAM. Ketika aplikasi mencoba membaca dari S3, token ditukar dengan satu set kredenSIAL IAM sementara yang menyerupai ini:

{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROA36C6WWEJULFUYMPB6:abc",
        "Arn": "arn:aws:sts::123456789012:assumed-role/eksctl-winterfell-addon-iamserviceaccount-de-Role1-1D61LT75JH3MB/abc"
    },
    "Audience": "sts.amazonaws.com",
    "Provider": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128",
    "SubjectFromWebIdentityToken": "system:serviceaccount:default:s3-read-only",
    "Credentials": {
        "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
        "SessionToken": "FwoGZXIvYXdzEGMaDMLxAZkuLpmSwYXShiL9A1S0X87VBC1mHCrRe/pB2oesl1eXxUYnPJyC9ayOoXMvqXQsomq0xs6OqZ3vaa5Iw1HIyA4Cv1suLaOCoU3hNvOIJ6C94H1vU0siQYk7DIq9Av5RZeuE2FnOctNBvYLd3i0IZo1ajjc00yRK3v24VRq9nQpoPLuqyH2jzlhCEjXuPScPbi5KEVs9fNcOTtgzbVf7IG2gNiwNs5aCpN4Bv/Zv2A6zp5xGz9cWj2f0aD9v66vX4bexOs5t/YYhwuwAvkkJPSIGvxja0xRThnceHyFHKtj0Hbi/PWAtlI8YJcDX69cM30JAHDdQHltm/4scFptW1hlvMaPWReCAaCrsHrATyka7ttw5YlUyvZ8EPogj6fwHlxmrXM9h1BqdikomyJU00gm1FJelfP1zAwcyrxCnbRl3ARFrAt8hIlrT6Vyu8WvWtLxcI8KcLcJQb/LgkWsCTGlYcY8z3zkigJMbYn07ewTL5Ss7LazTJJa758I7PZan/v3xQHd5DEc5WBneiV3iOznDFgup0VAMkIviVjVCkszaPSVEdK2NU7jtrh6Jfm7bU/3P6ZGCkyDLIa8MBn9KPXeJd/yjTk5IifIwO/mDpGNUribg6TPxhzZ8b/XdZO1kS1gVgqjXyVCM+BRBh6C4H21w/eMzjCtDIpoxt5rGKL6Nu/IFMipoC4fgx6LIIHwtGYMG7SWQi7OsMAkiwZRg0n68/RqWgLzBt/4pfjSRYuk=",
        "Expiration": "2020-02-20T18:49:50Z",
        "AccessKeyId": "ASIAIOSFODNN7EXAMPLE"
    }
}

Webhook bermutasi yang berjalan sebagai bagian dari bidang kontrol EKS menyuntikkan AWS Role ARN dan jalur ke file token identitas web ke Pod sebagai variabel lingkungan. Nilai-nilai ini juga dapat diberikan secara manual.

AWS_ROLE_ARN=arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAME
AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token

Kubelet akan secara otomatis memutar token yang diproyeksikan ketika lebih tua dari 80% dari total TTL, atau setelah 24 jam. AWS SDK bertanggung jawab untuk memuat ulang token saat berputar. Untuk informasi lebih lanjut tentang IRSA, lihat https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-technical-overview.html.

Identitas Pod EKS

EKS Pod Identities adalah fitur yang diluncurkan di re:Invent 2023 yang memungkinkan Anda menetapkan peran IAM ke akun layanan kubernetes, tanpa perlu mengonfigurasi penyedia identitas Open Id Connect (OIDC) (IDP) untuk setiap cluster di akun AWS Anda. Untuk menggunakan EKS Pod Identity, Anda harus menerapkan agen yang berjalan sebagai DaemonSet pod pada setiap node pekerja yang memenuhi syarat. Agen ini tersedia untuk Anda sebagai EKS Add-on dan merupakan prasyarat untuk menggunakan fitur EKS Pod Identity. Aplikasi Anda harus menggunakan versi AWS SDK yang didukung untuk menggunakan fitur ini.

Saat Identitas Pod EKS dikonfigurasi untuk Pod, EKS akan memasang dan menyegarkan token identitas pod di/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token. Token ini akan digunakan oleh AWS SDK untuk berkomunikasi dengan EKS Pod Identity Agent, yang menggunakan token identitas pod dan peran IAM agen untuk membuat kredentif sementara untuk pod Anda dengan memanggil AssumeRoleForPodIdentity API. Token identitas pod yang dikirimkan ke pod Anda adalah JWT yang dikeluarkan dari cluster EKS Anda dan ditandatangani secara kriptografis, dengan klaim JWT yang sesuai untuk digunakan dengan EKS Pod Identities.

Untuk mempelajari lebih lanjut tentang EKS Pod Identities, silakan lihat blog ini.

Anda tidak perlu melakukan modifikasi apa pun pada kode aplikasi Anda untuk menggunakan EKS Pod Identities. Versi AWS SDK yang didukung akan secara otomatis menemukan kredenSIAL yang tersedia dengan EKS Pod Identities dengan menggunakan rantai penyedia kredensia. Seperti IRSA, identitas pod EKS menetapkan variabel di dalam pod Anda untuk mengarahkan mereka cara menemukan kredenSIAL AWS.

Bekerja dengan peran IAM untuk EKS Pod Identities

{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceOrgId": "${aws:ResourceOrgId}"
        }
      }
    }
  ]
}

AWS merekomendasikan penggunaan kunci kondisi seperti aws:SourceOrgId untuk membantu melindungi dari masalah wakil yang membingungkan lintas layanan. Dalam contoh kebijakan kepercayaan peran di atas, variabel tersebut ResourceOrgId adalah variabel yang sama dengan ID Organisasi AWS dari Organisasi AWS yang dimiliki akun AWS. EKS akan meneruskan nilai yang aws:SourceOrgId sama dengan itu saat mengambil peran dengan EKS Pod Identities.

Identitas Pod ABAC dan EKS

Ketika EKS Pod Identities mengambil peran IAM, itu menetapkan tag sesi berikut:

Tag sesi ini memungkinkan Anda menggunakan Kontrol Akses Berbasis A tribut (ABAC) untuk memberikan akses ke sumber daya AWS Anda hanya ke akun layanan kubernetes tertentu. Ketika melakukannya, sangat penting untuk memahami bahwa akun layanan kubernetes hanya unik dalam namespace, dan ruang nama kubernetes hanya unik dalam cluster EKS. Tag sesi ini dapat diakses di kebijakan AWS dengan menggunakan kunci kondisi aws:PrincipalTag/<tag-key> global, seperti aws:PrincipalTag/eks-cluster-arn

Misalnya, jika Anda ingin memberikan akses hanya ke akun layanan tertentu untuk mengakses sumber daya AWS di akun Anda dengan IAM atau kebijakan sumber daya, Anda perlu memeriksa eks-cluster-arn dan kubernetes-namespace menandai serta untuk memastikan bahwa hanya akun layanan dari cluster yang dituju yang memiliki akses ke sumber daya tersebut karena cluster lain dapat memiliki kubernetes-service-accounts dan kubernetes-namespaces yang identik. kubernetes-service-account

Contoh kebijakan S3 Bucket ini hanya memberikan akses ke objek di bucket S3 yang dilampirkan, hanya jika kubernetes-service-accountkubernetes-namespace,, eks-cluster-arn semua memenuhi nilai yang diharapkan, di mana cluster EKS dihosting di akun AWS111122223333.

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:root"
            },
            "Action": "s3:*",
            "Resource":            [
                "arn:aws:s3:::ExampleBucket/*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalTag/kubernetes-service-account": "s3objectservice",
                    "aws:PrincipalTag/eks-cluster-arn": "arn:aws:eks:us-west-2:111122223333:cluster/ProductionCluster",
                    "aws:PrincipalTag/kubernetes-namespace": "s3datanamespace"
                }
            }
        }
    ]
}

Identitas Pod EKS dibandingkan dengan IRSA

EKS Pod Identities dan IRSA adalah cara yang lebih disukai untuk mengirimkan kredenSIAL AWS sementara ke pod EKS Anda. Kecuali Anda memiliki kasus penggunaan khusus untuk IRSA, kami sarankan Anda menggunakan EKS Pod Identities saat menggunakan EKS. Tabel ini membantu membandingkan dua fitur.

Identitas dan Kredentif untuk Rekomendasi pod EKS

Perbarui daemonset aws-node untuk menggunakan IRSA

Saat ini, daemonset aws-node dikonfigurasi untuk menggunakan peran yang ditetapkan ke instans EC2 untuk menetapkan IP ke pod. Peran ini mencakup beberapa kebijakan yang dikelola AWS, misalnya Amazoneks_CNI_Policy dan EC2ContainerRegistryReadOnly yang secara efektif memungkinkan semua pod berjalan pada node ke ENI, alamat assign/unassign IP, attach/detach atau menarik gambar dari ECR. Karena ini menimbulkan risiko bagi cluster Anda, disarankan agar Anda memperbarui daemonset aws-node untuk menggunakan IRSA. Skrip untuk melakukan ini dapat ditemukan di repositori untuk panduan ini.

Daemonset aws-node mendukung EKS Pod Identities dalam versi v1.15.5 dan yang lebih baru.

Batasi akses ke profil instance yang ditetapkan ke node pekerja

Ketika Anda menggunakan Identitas Pod IRSA atau EKS, itu memperbarui rantai kredensia pod untuk menggunakan Identitas Pod IRSA atau EKS terlebih dahulu, namun, pod masih dapat mewarisi hak profil instance yang ditetapkan ke node pekerja. Untuk pod yang tidak memerlukan izin ini, Anda dapat memblokir akses ke metadata instans untuk membantu memastikan bahwa aplikasi Anda hanya memiliki izin yang mereka butuhkan, dan bukan node mereka.

Anda dapat memblokir akses ke metadata instance dengan mewajibkan instance untuk menggunakan IMDSv2 saja dan memperbarui jumlah hop menjadi 1 seperti pada contoh di bawah ini. Anda juga dapat menyertakan pengaturan ini dalam template peluncuran grup node. Jangan menonaktifkan metadata instance karena ini akan mencegah komponen seperti pengendali penghentian node dan hal-hal lain yang bergantung pada metadata instance agar tidak berfungsi dengan baik.

$ aws ec2 modify-instance-metadata-options --instance-id <value> --http-tokens required --http-put-response-hop-limit 1
...

Jika Anda menggunakan Terraform untuk membuat template peluncuran untuk digunakan dengan Grup Node Terkelola, tambahkan blok metadata untuk mengonfigurasi jumlah hop seperti yang terlihat dalam cuplikan kode ini:

tf hl_lines="7" resource "aws_launch_template" "foo" { name = "foo" …​ metadata_options { http_endpoint = "enabled" http_tokens = "required" http_put_response_hop_limit = 1 instance_metadata_tags = "enabled" } …​

Anda juga dapat memblokir akses pod ke metadata EC2 dengan memanipulasi iptables pada node. Untuk informasi lebih lanjut tentang metode ini, lihat Membatasi akses ke layanan metadata instans.

Jika Anda memiliki aplikasi yang menggunakan AWS SDK versi lama yang tidak mendukung IRSA atau EKS Pod Identities, Anda harus memperbarui versi SDK.

Cakupan kebijakan kepercayaan Peran IAM untuk Peran IRSA ke nama akun layanan, namespace, dan cluster

Kebijakan kepercayaan dapat dicakup ke Namespace atau akun layanan tertentu dalam Namespace. Saat menggunakan IRSA, yang terbaik adalah membuat kebijakan kepercayaan peran seeksplisit mungkin dengan menyertakan nama akun layanan. Ini akan secara efektif mencegah Pod lain dalam Namespace yang sama mengambil peran. CLI eksctl akan melakukan ini secara otomatis ketika Anda menggunakannya untuk membuat accounts/IAM peran layanan. Lihat https://eksctl.io/usage/iamserviceaccounts/ untuk informasi lebih lanjut.

Saat bekerja dengan IAM secara langsung, ini menambahkan kondisi ke dalam kebijakan kepercayaan peran yang menggunakan kondisi untuk memastikan :sub klaim adalah namespace dan akun layanan yang Anda harapkan. Sebagai contoh, sebelumnya kami memiliki token IRSA dengan sub klaim “system:serviceaccount:default:s3-read-only”. Ini adalah default namespace dan akun layanan adalahs3-read-only. Anda akan menggunakan kondisi seperti berikut untuk memastikan bahwa hanya akun layanan Anda di namespace tertentu dari cluster Anda yang dapat mengambil peran itu:

  "Condition": {
      "StringEquals": {
          "oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128:aud": "sts.amazonaws.com",
          "oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128:sub": "system:serviceaccount:default:s3-read-only"
      }
  }

Gunakan satu peran IAM per aplikasi

Dengan IRSA dan EKS Pod Identity, ini adalah praktik terbaik untuk memberikan setiap aplikasi peran IAM sendiri. Ini memberi Anda peningkatan isolasi karena Anda dapat memodifikasi satu aplikasi tanpa memengaruhi yang lain, dan memungkinkan Anda untuk menerapkan prinsip hak istimewa paling sedikit dengan hanya memberikan aplikasi izin yang dibutuhkan.

Saat menggunakan ABAC dengan EKS Pod Identity, Anda dapat menggunakan peran IAM umum di beberapa akun layanan dan mengandalkan atribut sesi mereka untuk kontrol akses. Ini sangat berguna saat beroperasi dalam skala besar, karena ABAC memungkinkan Anda beroperasi dengan peran IAM yang lebih sedikit.

Saat aplikasi Anda memerlukan akses ke IMDS, gunakan IMDSv2 dan tingkatkan batas hop pada instans EC2 menjadi 2

IMDSv2 mengharuskan Anda menggunakan permintaan PUT untuk mendapatkan token sesi. Permintaan PUT awal harus menyertakan TTL untuk token sesi. Versi AWS SDK yang lebih baru akan menangani ini dan pembaruan token tersebut secara otomatis. Penting juga untuk diketahui bahwa batas hop default pada instans EC2 sengaja diatur ke 1 untuk mencegah penerusan IP. Akibatnya, Pod yang meminta token sesi yang dijalankan pada instans EC2 pada akhirnya dapat habis waktu dan mundur untuk menggunakan aliran data IMDsv1. EKS menambahkan dukungan IMDSv2 dengan mengaktifkan v1 dan v2 dan mengubah batas hop menjadi 2 pada node yang disediakan oleh eksctl atau dengan template resmi. CloudFormation

Nonaktifkan pemasangan otomatis token akun layanan

Jika aplikasi Anda tidak perlu memanggil API Kubernetes, atur automountServiceAccountToken atribut ke false dalam PodSpec untuk aplikasi Anda atau tambal akun layanan default di setiap namespace sehingga tidak lagi dipasang ke pod secara otomatis. Contoh:

kubectl patch serviceaccount default -p $'automountServiceAccountToken: false'

Gunakan akun layanan khusus untuk setiap aplikasi

Setiap aplikasi harus memiliki akun layanan khusus sendiri. Ini berlaku untuk akun layanan untuk API Kubernetes serta IRSA dan EKS Pod Identity.

Jalankan aplikasi sebagai pengguna non-root

Kontainer berjalan sebagai root secara default. Meskipun ini memungkinkan mereka untuk membaca file token identitas web, menjalankan wadah sebagai root tidak dianggap sebagai praktik terbaik. Sebagai alternatif, pertimbangkan untuk menambahkan spec.securityContext.runAsUser atribut ke PodSpec. Nilai runAsUser adalah nilai arbitrer.

Dalam contoh berikut, semua proses dalam Pod akan berjalan di bawah ID pengguna yang ditentukan di runAsUser bidang.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]

Ketika Anda menjalankan wadah sebagai pengguna non-root, kontainer mencegah membaca token akun layanan IRSA karena token tersebut diberi izin 0600 [root] secara default. Jika Anda memperbarui SecurityContext untuk wadah Anda untuk menyertakan fsgroup=65534 [Nobody] itu akan memungkinkan wadah untuk membaca token.

spec:
  securityContext:
    fsGroup: 65534

Di Kubernetes 1.19 dan di atasnya, perubahan ini tidak lagi diperlukan dan aplikasi dapat membaca token akun layanan IRSA tanpa menambahkannya ke grup Nobody.

Berikan akses paling tidak istimewa ke aplikasi

Action Hero adalah utilitas yang dapat Anda jalankan bersama aplikasi Anda untuk mengidentifikasi panggilan AWS API dan izin IAM terkait yang dibutuhkan aplikasi Anda agar berfungsi dengan baik. Ini mirip dengan Penasihat Akses IAM karena membantu Anda secara bertahap membatasi ruang lingkup peran IAM yang ditetapkan ke aplikasi. Lihat dokumentasi tentang pemberian akses yang kurang istimewa ke sumber daya AWS untuk informasi lebih lanjut.

Pertimbangkan untuk menetapkan batas izin pada peran IAM yang digunakan dengan IRSA dan Identitas Pod. Anda dapat menggunakan batas izin untuk memastikan bahwa peran yang digunakan oleh IRSA atau Identitas Pod tidak dapat melebihi tingkat izin maksimum. Untuk contoh panduan tentang memulai dengan batas izin dengan contoh kebijakan batas izin, silakan lihat re po github ini.

Tinjau dan cabut akses anonim yang tidak perlu ke cluster EKS Anda

Idealnya akses anonim harus dinonaktifkan untuk semua tindakan API. Akses anonim diberikan dengan membuat RoleBinding atau ClusterRoleBinding untuk sistem pengguna bawaan Kubernetes: anonymous. Anda dapat menggunakan alat rbac-lookup untuk mengidentifikasi izin yang dimiliki pengguna system:anonymous pada cluster Anda:

./rbac-lookup | grep -P 'system:(anonymous)|(unauthenticated)'
system:anonymous               cluster-wide        ClusterRole/system:discovery
system:unauthenticated         cluster-wide        ClusterRole/system:discovery
system:unauthenticated         cluster-wide        ClusterRole/system:public-info-viewer

Peran apa pun atau ClusterRole selain system:public-info-viewer tidak boleh terikat ke system:anonymous user atau system:unauthenticated group.

Mungkin ada beberapa alasan yang sah untuk mengaktifkan akses anonim pada API tertentu. Jika ini terjadi pada cluster Anda, pastikan bahwa hanya API tertentu yang dapat diakses oleh pengguna anonim dan mengekspos API tersebut tanpa otentikasi tidak membuat cluster Anda rentan.

Sebelum Kubernetes/EKS Versi 1.14, system:unauthenticated group dikaitkan dengan system:discovery dan system:basic-user secara default. ClusterRoles Perhatikan bahwa meskipun Anda telah memperbarui cluster ke versi 1.14 atau yang lebih tinggi, izin ini mungkin masih diaktifkan di cluster Anda, karena pembaruan cluster tidak mencabut izin ini. Untuk memeriksa mana yang ClusterRoles memiliki “system:unauthenticated” kecuali system:public-info-viewer Anda dapat menjalankan perintah berikut (memerlukan jq util):

kubectl get ClusterRoleBinding -o json | jq -r '.items[] | select(.subjects[]?.name =="system:unauthenticated") | select(.metadata.name != "system:public-info-viewer") | .metadata.name'

Dan “system:unauthenticated” dapat dihapus dari semua peran kecuali “system:public-info-viewer” menggunakan:

kubectl get ClusterRoleBinding -o json | jq -r '.items[] | select(.subjects[]?.name =="system:unauthenticated") | select(.metadata.name != "system:public-info-viewer") | del(.subjects[] | select(.name =="system:unauthenticated"))' | kubectl apply -f -

Atau, Anda dapat memeriksa dan menghapusnya secara manual dengan kubectl description dan kubectl edit. Untuk memeriksa apakah system:unauthenticated group memiliki izin system:discovery pada cluster Anda jalankan perintah berikut:

kubectl describe clusterrolebindings system:discovery

Name:         system:discovery
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
Role:
  Kind:  ClusterRole
  Name:  system:discovery
Subjects:
  Kind   Name                    Namespace
  ----   ----                    ---------
  Group  system:authenticated
  Group  system:unauthenticated

Untuk memeriksa apakah system:unauthenticated group memiliki izin system:basic-user pada cluster Anda jalankan perintah berikut:

kubectl describe clusterrolebindings system:basic-user

Name:         system:basic-user
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
Role:
  Kind:  ClusterRole
  Name:  system:basic-user
Subjects:
  Kind   Name                    Namespace
  ----   ----                    ---------
  Group  system:authenticated
  Group  system:unauthenticated

Jika system:unauthenticated group terikat ke system:discovery system: and/or basic-user ClusterRoles di cluster Anda, Anda harus memisahkan peran ini dari system:unauthenticated group. Edit system:discovery ClusterRoleBinding menggunakan perintah berikut:

kubectl edit clusterrolebindings system:discovery

Perintah di atas akan membuka definisi system:discovery saat ini di editor seperti yang ditunjukkan ClusterRoleBinding di bawah ini:

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2021-06-17T20:50:49Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:discovery
  resourceVersion: "24502985"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/system%3Adiscovery
  uid: b7936268-5043-431a-a0e1-171a423abeb6
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:discovery
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:unauthenticated

Hapus entri untuk grup system:unauthenticated dari bagian “subjek” di layar editor di atas.

Ulangi langkah yang sama untuk system: ClusterRoleBinding basic-user.

Gunakan kembali sesi AWS SDK dengan IRSA

Saat Anda menggunakan IRSA, aplikasi yang ditulis menggunakan AWS SDK menggunakan token yang dikirimkan ke pod Anda untuk dipanggil sts:AssumeRoleWithWebIdentity untuk menghasilkan kredenSIAL AWS sementara. Ini berbeda dari layanan komputasi AWS lainnya, di mana layanan komputasi memberikan kredenSIAL AWS sementara langsung ke sumber daya komputasi AWS, seperti fungsi lambda. Ini berarti bahwa setiap kali sesi AWS SDK diinisialisasi, panggilan ke AWS STS untuk AssumeRoleWithWebIdentity dilakukan. Jika aplikasi Anda menskalakan dengan cepat dan menginisialisasi banyak sesi AWS SDK, Anda mungkin mengalami pelambatan dari AWS STS karena kode Anda akan membuat banyak panggilan. AssumeRoleWithWebIdentity

Untuk menghindari skenario ini, sebaiknya gunakan kembali sesi AWS SDK dalam aplikasi Anda sehingga panggilan yang tidak perlu AssumeRoleWithWebIdentity tidak dilakukan.

Dalam kode contoh berikut, sesi dibuat menggunakan boto3 python SDK, dan sesi yang sama digunakan untuk membuat klien dan berinteraksi dengan Amazon S3 dan Amazon SQS. AssumeRoleWithWebIdentityhanya dipanggil sekali, dan AWS SDK akan menyegarkan kredenSIAL my_session saat kedaluwarsa secara otomatis.

import boto3

= Create your own session

my_session = boto3.session.Session()

= Now we can create low-level clients from our session

sqs = my_session.client('`sqs`') s3 = my_session.client('`s3`')

s3response = s3.list_buckets() sqsresponse = sqs.list_queues()

#print the response from the S3 and SQS APIs print("`s3 response:`")
print(s3response) print("`—`") print("`sqs response:`")
print(sqsresponse)

Jika Anda memigrasikan aplikasi dari layanan komputasi AWS lain, seperti EC2, ke EKS dengan IRSA, ini adalah detail yang sangat penting. Pada layanan komputasi lain, menginisialisasi sesi AWS SDK tidak memanggil AWS STS kecuali Anda memerintahkannya.

Pendekatan alternatif

Meskipun Identitas Pod IRSA dan EKS adalah cara yang lebih disukai untuk menetapkan identitas AWS ke pod, mereka mengharuskan Anda menyertakan versi terbaru dari AWS SDK dalam aplikasi Anda. Untuk daftar lengkap SDK yang saat ini mendukung IRSA, lihat, untuk Identitas Pod EKShttps://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-minimum-sdk.html, lihat https://docs.aws.amazon.com/eks/latest/userguide/pod-id-minimum-sdk.html. Jika Anda memiliki aplikasi yang tidak dapat segera Anda perbarui dengan SDK yang kompatibel, ada beberapa solusi berbasis komunitas yang tersedia untuk menetapkan peran IAM ke pod Kubernetes, termasuk kube2iam dan kiam. https://github.com/jtblin/kube2iam https://github.com/uswitch/kiam Meskipun AWS tidak mendukung, memaafkan, atau mendukung penggunaan solusi ini, solusi ini sering digunakan oleh komunitas secara luas untuk mencapai hasil yang sama seperti IRSA dan EKS Pod Identities.

Jika Anda perlu menggunakan salah satu solusi yang tidak disediakan aws ini, harap lakukan uji tuntas dan pastikan Anda memahami implikasi keamanan dari melakukannya.

Alat dan Sumber Daya