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 menjalankan 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 seperti Pengguna atau Peran IAM. Aturan yang mengatur tindakan yang diizinkan untuk dilakukan sumber daya dinyatakan sebagai kebijakan IAM.

Mengontrol Akses ke Kluster EKS

Proyek Kubernetes mendukung berbagai strategi berbeda untuk mengautentikasi permintaan ke layanan kube-apiserver, misalnya Token Pembawa, sertifikat X.509, OIDC, dll. 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 aws-iam-authenticatorklien saat Anda kubectl menjalankan perintah. 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 badan token. URL ini memvalidasi tanda tangan permintaan dan mengembalikan informasi tentang pengguna, misalnya akun pengguna, Arn, dan UserId ke kube-apiserver.

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

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

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 mencakup kredensi dan tanda tangan Amazon. Untuk detail tambahan lihat https://docs.aws.amazon.com/STS/latest/APIReference/API_ GetCallerIdentity .html.

Token memiliki waktu untuk 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 perlu membuat token baru dan mengautentikasi ulang setiap kali token kedaluwarsa.

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

Manajer Akses Cluster

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

API ini bergantung pada dua konsep:

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

Cluster Access Manager memungkinkan kombinasi RBAC hulu dengan Kebijakan Akses yang mendukung allow dan pass (tetapi tidak ditolak) 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 klaster dapat membuat atau memperbarui kluster Amazon EKS, menyetel autentikasi pilihan ke API_AND_CONFIG_MAP atau API metode, dan menentukan Entri Akses untuk memberikan akses kepada 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 kluster 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 dan kemudian keAPI_AND_CONFIG_MAP. 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

Perintah dukungan API untuk menambah dan mencabut akses ke klaster, serta memvalidasi Kebijakan Akses dan Entri Akses yang ada untuk klaster yang ditentukan. Kebijakan default dibuat untuk mencocokkan Kubernetes RBACs 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": []
}

Entri Akses tidak tersedia saat klaster dibuat tanpa izin admin pembuat klaster, yang merupakan satu-satunya entri yang dibuat secara default.

aws-auth ConfigMap (usang)

Salah satu cara integrasi Kubernetes dengan autentikasi AWS dapat dilakukan adalah melalui aws-auth ConfigMap, yang berada di Namespace. kube-system Ini bertanggung jawab untuk memetakan autentikasi AWS IAM Identities (Users, Groups, and Roles), ke otorisasi kontrol akses berbasis peran (RBAC) Kubernetes. aws-auth ConfigMap Ini secara otomatis dibuat di kluster Amazon EKS Anda selama fase penyediaannya. Awalnya dibuat untuk memungkinkan node bergabung dengan cluster Anda, tetapi seperti yang disebutkan Anda juga dapat menggunakan ini ConfigMap untuk menambahkan RBACs akses 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 file 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, berada data di bawah mapRoles blok, yang pada dasarnya disusun oleh 3 parameter.

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

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

Rekomendasi Akses Cluster

Jadikan EKS Cluster Endpoint pribadi

Secara default saat Anda menyediakan kluster EKS, titik akhir klaster API disetel ke publik, yaitu dapat diakses dari Internet. Meskipun dapat diakses dari Internet, titik akhir masih dianggap aman karena mengharuskan semua permintaan API untuk diautentikasi oleh IAM dan kemudian disahkan oleh Kubernetes RBAC. Karena itu, jika kebijakan keamanan perusahaan Anda mengamanatkan bahwa Anda membatasi akses ke API dari Internet atau mencegah Anda merutekan lalu lintas di luar VPC klaster, 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. Terkadang, Anda mungkin perlu memberikan pengecualian untuk aplikasi yang harus menggunakan Kubernetes API dari luar klaster, misalnya aplikasi pipeline CI/CD. Jika aplikasi tersebut berjalan pada infrastruktur AWS, seperti EC2 instance, pertimbangkan untuk menggunakan profil instance dan memetakannya ke peran Kubernetes RBAC.

Gunakan akses yang paling tidak istimewa ke AWS Resources

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

Hapus izin cluster-admin dari prinsipal pembuat klaster

Secara default, klaster Amazon EKS dibuat dengan cluster-admin izin permanen yang terikat pada prinsipal pembuat klaster. Dengan Cluster Access Manager API, dimungkinkan untuk membuat cluster tanpa izin ini menyetel --access-config bootstrapClusterCreatorAdminPermissions kefalse, saat menggunakan API_AND_CONFIG_MAP atau mode API otentikasi. Cabut akses ini yang 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 skenario insiden, darurat atau pecah kaca di mana cluster tidak dapat diakses.

Jika klaster 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 pecah kaca, atau di mana rusak dan klaster aws-auth ConfigMap tidak dapat diakses. Ini bisa sangat berguna dalam kelompok produksi.

Gunakan Peran IAM saat beberapa pengguna membutuhkan akses identik ke cluster

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

Jika masih menggunakan aws-auth ConfigMap sebagai metode otentikasi, saat menetapkan izin K8s RBAC ke peran IAM, Anda harus menyertakan\ {{}} di nama pengguna Anda. SessionName Dengan begitu, log audit akan merekam nama sesi sehingga Anda dapat melacak siapa pengguna yang sebenarnya 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 dan RoleBindings ClusterRoleBindings

Seperti poin sebelumnya tentang pemberian akses ke AWS Resources, RoleBindings dan ClusterRoleBindings seharusnya hanya menyertakan serangkaian izin yang diperlukan untuk menjalankan fungsi tertentu. Hindari menggunakan ["*"] peran Anda dan ClusterRoles kecuali itu benar-benar diperlukan. Jika Anda tidak yakin izin apa yang akan 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 klaster Amazon EKS, jika tidak menggunakan mode using API_AND_CONFIG_MAP atau API autentikasi, dan tidak memilih untuk tidak mendelegasikan cluster-admin izin ke pembuat klaster, 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, merupakan ide yang baik untuk membuat cluster dengan pipa otomatisasi infrastruktur yang terkait dengan peran IAM khusus, tanpa izin untuk diasumsikan oleh pengguna atau entitas lain dan secara teratur mengaudit izin, kebijakan, dan siapa yang memiliki akses untuk memicu pipeline. Selain itu, peran ini tidak boleh digunakan untuk melakukan tindakan rutin di 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 klaster Amazon EKS, pengguna atau peran entitas IAM, seperti pengguna federasi yang membuat klaster, 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 merupakan 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 di 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 sementara yang ditinggikan /break glass 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. Berencana 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 open source seperti kubectl-who-can, atau rbac-lookup untuk memeriksa peran yang terikat pada akun layanan, pengguna, atau grup tertentu. Kami akan mengeksplorasi topik ini lebih lanjut ketika kami 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 dengan 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 lebih lanjut, tinjau eksctldokumen

aws-auth oleh keikoproj

aws-autholeh keikoproj mencakup perpustakaan cli dan go.

Unduh dan lihat bantuan bantuan CLI:

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

Atau, instal aws-auth dengan pengelola 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 klaster 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 mengautentikasi pengguna yang membutuhkan akses ke cluster EKS, dimungkinkan untuk menggunakan penyedia identitas OIDC seperti GitHub menggunakan proxy otentikasi dan peniruan identitas Kubernetes. Posting untuk dua solusi tersebut telah dipublikasikan di blog AWS Open Source:

Anda juga dapat menggunakan AWS SSO untuk menggabungkan 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 Kredensional untuk Pod EKS

Aplikasi tertentu yang berjalan di dalam klaster Kubernetes memerlukan izin untuk memanggil Kubernetes API agar berfungsi dengan baik. Misalnya, AWS Load Balancer Controller harus dapat mencantumkan Endpoint Layanan. Pengontrol juga harus dapat memanggil AWS APIs untuk menyediakan dan mengonfigurasi ALB. Di bagian ini kita akan mengeksplorasi praktik terbaik untuk menetapkan hak dan hak istimewa ke Pod.

Akun Layanan Kubernetes

Service account adalah jenis objek khusus yang memungkinkan Anda untuk menetapkan peran Kubernetes RBAC ke sebuah pod. Akun layanan default dibuat secara otomatis untuk setiap Namespace dalam sebuah cluster. Saat Anda menerapkan pod ke Namespace tanpa mereferensikan akun layanan tertentu, akun layanan default untuk Namespace tersebut akan secara otomatis ditetapkan ke Pod dan Secret, yaitu token akun layanan (JWT) untuk akun layanan tersebut, akan dipasang ke pod sebagai volume di. /var/run/secrets/kubernetes.io/serviceaccount Menguraikan kode 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 untuk Kubernetes API.

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 memberi wewenang kepada pengguna yang tidak diautentikasi dan diautentikasi untuk membaca informasi API dan dianggap aman agar dapat diakses publik.

Ketika sebuah aplikasi yang berjalan di dalam sebuah Pod memanggil Kubernetes APIs, Pod tersebut perlu diberi service account yang secara eksplisit memberikan izin untuk memanggilnya. APIs Mirip dengan pedoman untuk akses pengguna, Peran atau ClusterRole 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 atur spec.serviceAccountName 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 untuk menetapkan peran IAM ke akun layanan Kubernetes. Ia bekerja dengan memanfaatkan fitur Kubernetes yang dikenal sebagai Proyeksi Volume Token Akun Layanan. Ketika Pod dikonfigurasi dengan Service Account yang mereferensikan Peran IAM, server API Kubernetes akan memanggil titik akhir penemuan OIDC publik untuk klaster 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 untuk memanggil peran IAM APIs terkait AWS. Saat AWS API dipanggil, AWS akan SDKs memanggilsts:AssumeRoleWithWebIdentity. Setelah memvalidasi tanda tangan token, IAM menukar token yang dikeluarkan Kubernetes dengan kredensi peran AWS sementara.

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

Decoding 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 hanya tampilan Pod ke S3 dengan mengasumsikan peran IAM. Saat aplikasi mencoba membaca dari S3, token ditukar dengan seperangkat kredensyal 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 yang bermutasi yang berjalan sebagai bagian dari control plane EKS akan menyuntikkan AWS Role ARN dan path ke file token identitas web ke dalam 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 SDKs bertanggung jawab untuk memuat ulang token saat diputar. Untuk informasi lebih lanjut tentang IRSA, lihat https://docs.aws.amazon.com/eks/latest/userguide/iam- roles-for-service-accounts -technical-overview.html.

Identitas EKS Pod

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 (IDP) Open Id Connect (OIDC) 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 Add-on EKS dan merupakan prasyarat untuk menggunakan fitur EKS Pod Identity. Aplikasi Anda harus menggunakan AWS SDK versi yang didukung untuk menggunakan fitur ini.

Ketika EKS Pod Identities dikonfigurasi untuk sebuah Pod, EKS akan me-mount dan me-refresh 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 Agen Identitas Pod EKS, yang menggunakan token identitas pod dan peran IAM agen untuk membuat kredensyal sementara untuk pod Anda dengan memanggil API. AssumeRoleForPodIdentity 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 Identitas Pod EKS.

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 kredensyal yang tersedia dengan EKS Pod Identities dengan menggunakan rantai penyedia kredensyal. Seperti IRSA, identitas pod EKS menetapkan variabel di dalam pod Anda untuk mengarahkan mereka cara menemukan kredensyal 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 membantu melindungi dari masalah deputi lintas layanan yang membingungkan. Dalam contoh kebijakan kepercayaan peran di atas, variabel ResourceOrgId adalah variabel yang sama dengan AWS Organizations Organization ID dari AWS Organization yang menjadi milik akun AWS. EKS akan memberikan nilai yang aws:SourceOrgId sama dengan itu ketika mengasumsikan peran dengan EKS Pod Identities.

Identitas Pod ABAC dan EKS

Ketika EKS Pod Identities mengasumsikan peran IAM, ia menetapkan tag sesi berikut:

Tag sesi ini memungkinkan Anda menggunakan Attribute Based Access Control (ABAC) untuk memberikan akses ke resource AWS Anda hanya ke akun layanan kubernetes tertentu. Saat melakukannya, sangat penting untuk dipahami bahwa akun layanan kubernetes hanya unik di dalam namespace, dan namespace kubernetes hanya unik di dalam cluster EKS. Tag sesi ini dapat diakses dalam kebijakan AWS dengan menggunakan kunci kondisi aws:PrincipalTag/<tag-key> global, seperti aws:PrincipalTag/eks-cluster-arn

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

Contoh kebijakan Bucket S3 ini hanya memberikan akses ke objek di bucket S3 yang dilampirkan, hanya jika, kubernetes-service-accountkubernetes-namespace, eks-cluster-arn semuanya memenuhi nilai yang diharapkan, tempat cluster EKS di-host di akun AWS. 111122223333

{
    "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"
                }
            }
        }
    ]
}

EKS Pod Identitas dibandingkan dengan IRSA

Baik EKS Pod Identities dan IRSA adalah cara yang lebih disukai untuk mengirimkan kredensyal 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 Kredensyal untuk Rekomendasi Pod EKS

Perbarui daemonset aws-node untuk menggunakan IRSA

Saat ini, daemonset aws-node dikonfigurasi untuk menggunakan peran yang ditetapkan ke EC2 instance untuk ditetapkan ke pod. IPs Peran ini mencakup beberapa kebijakan yang dikelola AWS, misalnya Amazoneks_CNI_Policy EC2 ContainerRegistryReadOnly dan yang secara efektif memungkinkan semua pod yang berjalan pada node ke, alamat IP, atau menarik gambar dari ECR. attach/detach ENIs assign/unassign Karena ini menimbulkan risiko bagi cluster Anda, Anda disarankan untuk 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

Saat Anda menggunakan IRSA atau EKS Pod Identities, Pod akan memperbarui rantai kredensialnya untuk menggunakan IRSA atau EKS Pod Identities terlebih dahulu, namun pod tersebut masih dapat mewarisi hak dari profil instance yang ditetapkan ke node pekerja. Untuk pod yang tidak memerlukan izin ini, Anda dapat memblokir akses ke metadata instance untuk membantu memastikan bahwa aplikasi Anda hanya memiliki izin yang diperlukan, dan bukan node mereka.

Anda dapat memblokir akses ke metadata instance dengan mengharuskan instance IMDSv2 hanya menggunakan dan memperbarui jumlah hop ke 1 seperti pada contoh di bawah ini. Anda juga dapat menyertakan pengaturan ini dalam template peluncuran grup node. Jangan nonaktifkan metadata instance karena ini akan mencegah komponen seperti pengendali terminasi node dan hal-hal lain yang mengandalkan 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 templat 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 EC2 metadata dengan memanipulasi iptables pada node. Untuk informasi lebih lanjut tentang metode ini, lihat Membatasi akses ke layanan metadata instance.

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 klaster

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 memasukkan nama akun layanan. Ini akan secara efektif mencegah Pod lain dalam Namespace yang sama untuk mengambil peran tersebut. CLI eksctl akan melakukan ini secara otomatis ketika Anda menggunakannya untuk membuat peran layanan accounts/IAM . 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, sebelum kita memiliki token IRSA dengan sub klaim “system:serviceaccount:default:s3-read-only”. Ini adalah default namespace dan akun layanannya. s3-read-only Anda akan menggunakan kondisi seperti berikut ini 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 masing-masing aplikasi peran IAM sendiri. Ini memberi Anda isolasi yang lebih baik karena Anda dapat memodifikasi satu aplikasi tanpa memengaruhi yang lain, dan memungkinkan Anda menerapkan prinsip hak istimewa paling sedikit dengan hanya memberikan izin yang dibutuhkan aplikasi.

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 membutuhkan akses ke IMDS, gunakan IMDSv2 dan tingkatkan batas hop pada EC2 instance menjadi 2

IMDSv2mengharuskan Anda menggunakan permintaan PUT untuk mendapatkan token sesi. Permintaan PUT awal harus menyertakan TTL untuk token sesi. Versi AWS yang lebih baru SDKs akan menangani ini dan pembaruan token tersebut secara otomatis. Penting juga untuk menyadari bahwa batas hop default pada EC2 instance sengaja diatur ke 1 untuk mencegah penerusan IP. Akibatnya, Pod yang meminta token sesi yang dijalankan pada EC2 instance pada akhirnya dapat habis waktu dan mundur 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 templat resmi. CloudFormation

Nonaktifkan pemasangan otomatis token akun layanan

Jika aplikasi Anda tidak perlu memanggil Kubernetes API, setel automountServiceAccountToken atribut ke false in PodSpec for your application atau patch akun layanan default di setiap namespace sehingga tidak lagi terpasang ke pod secara otomatis. Misalnya:

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 Kubernetes API 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 dalam 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" ]

Saat Anda menjalankan penampung sebagai pengguna non-root, penampung mencegah penampung membaca token akun layanan IRSA karena token diberi izin 0600 [root] secara default. Jika Anda memperbarui SecurityContext untuk container Anda untuk menyertakan fsgroup=65534 [Nobody] itu akan memungkinkan penampung 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 untuk berfungsi dengan baik. Ini mirip dengan IAM Access Advisor karena membantu Anda secara bertahap membatasi ruang lingkup peran IAM yang ditetapkan untuk aplikasi. Lihat dokumentasi tentang pemberian akses istimewa paling sedikit ke sumber daya AWS untuk informasi lebih lanjut.

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

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

Idealnya akses anonim harus dinonaktifkan untuk semua tindakan API. Akses anonim diberikan dengan membuat RoleBinding atau ClusterRoleBinding untuk sistem pengguna bawaan Kubernetes:anonim. Anda dapat menggunakan alat rbac-lookup untuk mengidentifikasi izin yang dimiliki pengguna system:anonymous di 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 sistem: tidak public-info-viewer boleh terikat pada sistem: pengguna anonim atau grup system:unauthenticated.

Mungkin ada beberapa alasan yang sah untuk mengaktifkan akses anonim secara spesifik APIs. Jika hal ini terjadi pada klaster Anda, pastikan bahwa hanya yang spesifik APIs yang dapat diakses oleh pengguna anonim dan mengekspos mereka APIs tanpa otentikasi tidak membuat cluster Anda rentan.

Sebelum Kubernetes/EKS Versi 1.14, grup system:unauthenticated dikaitkan dengan system:discovery dan system:basic-user secara default. ClusterRoles Perhatikan bahwa meskipun Anda telah memperbarui klaster ke versi 1.14 atau lebih tinggi, izin ini mungkin masih diaktifkan di klaster Anda, karena pembaruan klaster tidak mencabut izin ini. Untuk memeriksa yang ClusterRoles memiliki “system:unauthenticated” kecuali system: public-info-viewer Anda dapat menjalankan perintah berikut (membutuhkan 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:" menggunakan: public-info-viewer

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 describe dan kubectl edit. Untuk memeriksa apakah grup system:unauthenticated memiliki izin system:discovery di 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 system:basic-user permission 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 grup system:unauthenticated terikat pada system:discovery dan/atau system:basic-user di cluster Anda, Anda harus memisahkan peran ini dari grup ClusterRoles system:unauthenticated. 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 “subyek” di layar editor di atas.

Ulangi langkah yang sama untuk ClusterRoleBinding system: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 sts:AssumeRoleWithWebIdentity untuk menelepon guna menghasilkan kredensyal AWS sementara. Ini berbeda dengan layanan komputasi AWS lainnya, di mana layanan komputasi memberikan kredensyal 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 pembatasan 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 contoh kode 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 kredensyal my_session kapan mereka 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 yang menginisialisasi sesi AWS SDK tidak memanggil AWS STS kecuali Anda menginstruksikannya.

Pendekatan alternatif

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

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

Alat dan Sumber Daya