AWS IAM Authenticator for Kubernetes

A tool to use AWS IAM credentials to authenticate to a Kubernetes cluster. The initial work on this tool was driven by Heptio. The project receives contributions from multiple community engineers and is currently maintained by Heptio and Amazon EKS OSS Engineers.

Table of Contents

• Why do I want this?
• How do I use it?
• Kops Usage
• How does it work?
• What is a cluster ID?
• Specifying Credentials & Using AWS Profiles
• API Authorization from Outside a Cluster
• Troubleshooting
• Full Configuration Format
• Development
• Community, discussion, contribution, and support

मुझे यह क्यों चाहिए?

यदि आप AWS पर Kubernetes क्लस्टर चलाने वाले प्रशासक हैं, तो आपको पहले से ही क्लस्टर प्रावधान और अपडेट करने के लिए AWS IAM क्रेडेंशियल्स प्रबंधित करने की आवश्यकता होती है। AWS IAM Authenticator for Kubernetes का उपयोग करके, आप Kubernetes एक्सेस के लिए एक अलग क्रेडेंशियल प्रबंधित करने से बच जाते हैं। AWS IAM कई अच्छे गुण भी प्रदान करता है, जैसे ऑडिट ट्रेल (CloudTrail के माध्यम से) और 2FA/MFA अनिवार्य करना।

यदि आप AWS पर Kubernetes इंस्टॉलर बना रहे हैं, तो AWS IAM Authenticator for Kubernetes आपकी बूटस्ट्रैप प्रक्रिया को सरल बना सकता है। आपको अपने नए इंस्टॉल किए गए क्लस्टर से प्रारंभिक एडमिन क्रेडेंशियल को किसी तरह सुरक्षित रूप से बाहर निकालने की आवश्यकता नहीं होगी। इसके बजाय, आप क्लस्टर प्रावधान के समय एक समर्पित KubernetesAdmin भूमिका बना सकते हैं और Authenticator को क्लस्टर व्यवस्थापक लॉगिन की अनुमति देने के लिए सेट कर सकते हैं।

मैं इसका उपयोग कैसे करूँ?

मान लें कि आपके पास AWS में चल रहा एक क्लस्टर है और आप AWS IAM Authenticator for Kubernetes समर्थन जोड़ना चाहते हैं, तो आपको निम्न कार्य करने होंगे:

1. उपयोगकर्ताओं की पहचान के लिए उपयोग होने वाली IAM भूमिका बनाएँ।
2. Authenticator सर्वर को DaemonSet के रूप में चलाएँ।
3. अपने API सर्वर को Authenticator से संवाद करने के लिए कॉन्फ़िगर करें।
4. Authenticator टोकन का उपयोग करने के लिए kubectl सेट करें।

1. IAM भूमिका बनाएँ

सबसे पहले, आपको एक या अधिक IAM भूमिकाएँ बनानी होंगी जो आपके Kubernetes क्लस्टर के अंदर उपयोगकर्ताओं/समूहों से मैप की जाएँगी। ऐसा करने का सबसे आसान तरीका AWS Console में लॉग इन करना है:

• "Role for cross-account access" / "Provide access between AWS accounts you own" विकल्प चुनें।
• अपना AWS खाता ID नंबर पेस्ट करें (कंसोल में ऊपर दाईं ओर उपलब्ध)।
• आपकी भूमिका के साथ कोई अतिरिक्त नीति संलग्न करने की आवश्यकता नहीं है।

यह आपके खाते में अधिकृत उपयोगकर्ताओं/भूमिकाओं द्वारा ग्रहण की जा सकने वाली बिना किसी अनुमति वाली IAM भूमिका बनाएगा। अपनी भूमिका के Amazon Resource Name (ARN) पर ध्यान दें, जिसकी आपको नीचे आवश्यकता होगी।

आप AWS Console के बजाय AWS CLI का उपयोग करके भी यह एक ही चरण में कर सकते हैं:```sh

get your account ID

ACCOUNT_ID=$(aws sts get-caller-identity --output text --query 'Account')

define a role trust policy that opens the role to users in your account (limited by IAM policy)

POLICY=$(echo -n '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::'; echo -n "$ACCOUNT_ID"; echo -n ':root"},"Action":"sts:AssumeRole","Condition":{}}]}')

create a role named KubernetesAdmin (will print the new role's ARN)

aws iam create-role
--role-name KubernetesAdmin
--description "Kubernetes administrator role (for AWS IAM Authenticator for Kubernetes)."
--assume-role-policy-document "$POLICY"
--output text
--query 'Role.Arn'

आप इस चरण को भी छोड़ सकते हैं और निम्नलिखित का उपयोग कर सकते हैं:
 - एक मौजूदा role (जैसे cross-account access role)।
 - एक IAM user (नीचे `mapUsers` देखें)।
 - एक EC2 instance या एक federated role (नीचे `mapRoles` देखें)।

### 2. सर्वर चलाएं
सर्वर को आपके प्रत्येक मास्टर नोड पर DaemonSet के रूप में host networking के साथ चलाया जाना है, ताकि यह एक localhost पोर्ट को उजागर कर सके।

नमूना ConfigMap और DaemonSet कॉन्फ़िगरेशन के लिए, [`deploy/example.yaml`](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/HEAD/deploy/example.yaml) देखें।
इसे लागू करने से पहले, अपने क्लस्टर के लिए इन मानों को अपडेट करें:
 - `config.yaml` में प्लेसहोल्डर IAM ARNs (`arn:aws:iam::000000000000:...`) बदलें।
 - `clusterID` को अपने क्लस्टर के लिए एक अद्वितीय मान पर सेट करें।
 - सत्यापित करें कि DaemonSet शेड्यूलिंग नियम आपके control-plane node labels/taints से मेल खाते हैं।

फिर इसे डिप्लॉय करें:```sh
kubectl apply -f deploy/example.yaml
kubectl -n kube-system rollout status daemonset/aws-iam-authenticator
kubectl -n kube-system get pods -l k8s-app=aws-iam-authenticator

जब पॉड कंट्रोल-प्लेन नोड पर चल रहा होता है, तो aws-iam-authenticator server होस्ट पर /etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml (या --generate-kubeconfig के माध्यम से कॉन्फ़िगर किया गया पथ) पर वेबहुक kubeconfig बनाएगा।

(वैकल्पिक) प्रमाणपत्र, कुंजी और kubeconfig पहले से जनरेट करें

यदि आप एक स्वचालित इंस्टॉलर बना रहे हैं, तो आप aws-iam-authenticator init का उपयोग करके प्रमाणपत्र, कुंजी और वेबहुक kubeconfig फ़ाइलें आसानी से पहले से जनरेट कर सकते हैं। यह कमांड फ़ाइलें जनरेट करेगा और उन्हें कॉन्फ़िगर किए गए आउटपुट निर्देशिकाओं में रखेगा।

आप API सर्वर शुरू करने से पहले प्रत्येक मास्टर नोड पर इसे चला सकते हैं। आप मास्टर नोड्स प्रोविज़न करने से पहले भी उन्हें जनरेट कर सकते हैं और उन्हें उपयुक्त होस्ट पथों में इंस्टॉल कर सकते हैं।

यदि आप फ़ाइलें पहले से जनरेट नहीं करते हैं, तो aws-iam-authenticator server उन्हें मांग पर जनरेट करेगा। यह काम करता है, लेकिन इसके लिए आवश्यक है कि आप इंस्टॉलेशन के बाद अपने Kubernetes API सर्वर को पुनः आरंभ करें।

3. अपने API सर्वर को सर्वर से बात करने के लिए कॉन्फ़िगर करें

Kubernetes API, टोकन प्रमाणीकरण वेबहुक का उपयोग करके AWS IAM Authenticator for Kubernetes के साथ एकीकृत होता है। जब आप aws-iam-authenticator server चलाते हैं, तो यह एक वेबहुक कॉन्फ़िगरेशन फ़ाइल जनरेट करेगा और उसे होस्ट फाइलसिस्टम पर सहेजेगा। आपको अपने API सर्वर कॉन्फ़िगरेशन में एक अतिरिक्त फ़्लैग जोड़ने की आवश्यकता होगी:``` --authentication-token-webhook-config-file=/etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml

कई क्लस्टरों पर, API server एक static pod के रूप में चलता है।
आप फ़्लैग को `/etc/kubernetes/manifests/kube-apiserver.yaml` में जोड़ सकते हैं।
सुनिश्चित करें कि होस्ट डायरेक्टरी `/etc/kubernetes/aws-iam-authenticator/` आपके API server pod में माउंट की गई है।
अपडेटेड static pod परिभाषा को लागू करने के लिए आपको अपने master node पर kubelet daemon को पुनः आरंभ करने की आवश्यकता हो सकती है:```
systemctl restart kubelet.service

4. IAM भूमिका/उपयोगकर्ता को kubernetes उपयोगकर्ता/समूह मैपिंग में बनाएँ

सर्वर का डिफ़ॉल्ट व्यवहार मैपिंग को केवल अपनी कॉन्फ़िगरेशन फ़ाइल के mapUsers और mapRoles फ़ील्ड से प्राप्त करना है। विवरण के लिए नीचे Full Configuration Format देखें।

--backend-mode फ़्लैग का उपयोग करके, आप सर्वर को दो अतिरिक्त बैकएंड से मैपिंग प्राप्त करने के लिए कॉन्फ़िगर कर सकते हैं: एक EKS-शैली ConfigMap (--backend-mode=EKSConfigMap) या IAMIdentityMapping कस्टम संसाधन (--backend-mode=CRD)। डिफ़ॉल्ट बैकएंड, सर्वर कॉन्फ़िगरेशन फ़ाइल जो सर्वर पॉड द्वारा माउंट की जाती है, --backend-mode=MountedFile से मेल खाती है।

आप सर्वर को क्रम में खोजने के लिए इन बैकएंड की अल्पविराम-पृथक सूची पास कर सकते हैं। उदाहरण के लिए, --backend-mode=EKSConfigMap,MountedFile के साथ, सर्वर पहले EKS-शैली ConfigMap में मैपिंग खोजेगा और फिर, यदि दिए गए IAM भूमिका/उपयोगकर्ता के लिए मैपिंग नहीं मिलती है, तो सर्वर कॉन्फ़िगरेशन फ़ाइल में खोजेगा। यदि एक ही IAM भूमिका/उपयोगकर्ता के लिए मैपिंग कई बैकएंड में मौजूद है, तो सर्वर उस बैकएंड की मैपिंग का उपयोग करेगा जो अल्पविराम-पृथक सूची में पहले आता है। इस उदाहरण में, यदि EKS ConfigMap में मैपिंग मिलती है तो उसका उपयोग किया जाएगा, चाहे सर्वर कॉन्फ़िगरेशन फ़ाइल में कोई डुप्लिकेट या विरोधी मैपिंग मौजूद हो या नहीं।

ध्यान दें कि एकल बैकएंड सेट करते समय, सर्वर केवल उसी से प्राप्त करेगा और दूसरों को अनदेखा करेगा, भले ही वे मौजूद हों। उदाहरण के लिए, --backend-mode=CRD के साथ, सर्वर केवल IAMIdentityMappings से प्राप्त करेगा और माउंट की गई फ़ाइल और EKS ConfigMap को अनदेखा करेगा।

MountedFile

यह मैपिंग का डिफ़ॉल्ट बैकएंड है और अधिकांश उपयोगकर्ताओं के लिए पर्याप्त है। विवरण के लिए नीचे Full Configuration Format देखें।

CRD (अल्फा)

यह बैकएंड प्रत्येक IAM मैपिंग को एक IAMIdentityMapping Kubernetes Custom Resource के रूप में मॉडल करता है। यह दृष्टिकोण आपको kubectl या API का उपयोग करके Kubernetes-मूल तरीके से मैपिंग बनाए रखने में सक्षम बनाता है। साथ ही, सिंटैक्स त्रुटियाँ (जैसे गलत संरेखित YAML) अधिक आसानी से पकड़ी जा सकती हैं और सभी मैपिंग को प्रभावित नहीं करेंगी।

एक IAMIdentityMapping CRD सेटअप करने के लिए आपको पहले CRD मैनिफेस्ट को apply करना होगा:``` kubectl apply -f deploy/iamidentitymapping.yaml

CRDs तैनात होने के बाद, आप कस्टम संसाधन बना सकते हैं जो आपकी IAM पहचानों को मॉडल करते हैं। देखें
[`./deploy/example-iamidentitymapping.yaml`](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/HEAD/deploy/example-iamidentitymapping.yaml):```
---
apiVersion: iamauthenticator.k8s.aws/v1alpha1
kind: IAMIdentityMapping
metadata:
  name: kubernetes-admin
spec:
  # Arn of the User or Role to be allowed to authenticate
  arn: arn:aws:iam::XXXXXXXXXXXX:user/KubernetesAdmin
  # Username that Kubernetes will see the user as, this is useful for setting
  # up allowed specific permissions for different users
  username: kubernetes-admin
  # Groups to be attached to your users/roles. For example `system:masters` to
  # create cluster admin, or `system:nodes`, `system:bootstrappers` for nodes to
  # access the API server.
  groups:
  - system:masters

EKSConfigMap

EKS-शैली kube-system/aws-auth ConfigMap बैकएंड के रूप में कार्य करता है। ConfigMap EKS क्लस्टर्स के समान प्रारूप में होने की अपेक्षा की जाती है: https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html. यह तब उपयोगी है जब आप EKS से/में माइग्रेट कर रहे हैं और अपने मैपिंग्स को बनाए रखना चाहते हैं, या किसी अन्य AWS क्लस्टर(s) के अतिरिक्त EKS चला रहे हैं और प्रत्येक में समान मैपिंग्स चाहते हैं।

DynamicFile

cfg.dynamicfilepath द्वारा निर्दिष्ट एक स्थानीय फ़ाइल बैकएंड के रूप में कार्य कर सकती है। फ़ाइल सामग्री EKSConfigMap के समान प्रारूप में होने की अपेक्षा की जाती है। जब भी इस फ़ाइल की सामग्री बदलती है, authenticator इसे स्वचालित रूप से पुनः लोड करेगा। यह ARN मैपिंग्स के प्रबंधन में अधिक लचीलापन प्रदान करता है।

DynamicFile मोड को कैसे कॉन्फ़िगर करें, यह जानने के लिए https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/hack/dev/authenticator_with_dynamicfile_mode.yaml देखें।

DynamicFile मोड सक्षम के साथ kind क्लस्टर के साथ प्रयोग करने के लिए make e2e RUNNER=kind चलाएँ।

5. Kubernetes उपयोगकर्ता नामों के लिए reservedPrefixConfig कैसे कॉन्फ़िगर करें

aws-iam-authenticator k8s उपयोगकर्ता नाम के लिए आरक्षित उपसर्ग का समर्थन कर सकता है। यदि आरक्षित उपसर्ग सेट है, तो आरक्षित उपसर्ग वाले उपयोगकर्ता नाम को "username must not begin with with the following prefixes:" त्रुटि के साथ प्रमाणित नहीं किया जाएगा।

आरक्षित उपसर्ग को कैसे कॉन्फ़िगर करें, यह जानने के लिए https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/hack/dev/authenticator_with_dynamicfile_mode.yaml देखें।

6. AWS IAM Authenticator for Kubernetes द्वारा प्रदान किए गए प्रमाणीकरण टोकन का उपयोग करने के लिए kubectl सेट करें

अंत में, एक बार सर्वर सेट हो जाने के बाद आप प्रमाणित करना चाहेंगे। आपको अभी भी एक kubeconfig की आवश्यकता होगी जिसमें आपके क्लस्टर के बारे में सार्वजनिक डेटा हो (क्लस्टर CA प्रमाणपत्र, एंडपॉइंट पता)। आपके कॉन्फ़िगरेशन का users अनुभाग, हालाँकि, एक exec अनुभाग शामिल करना चाहिए (kubectl क्रेडेंशियल प्लगइन दस्तावेज़ देखें):```yaml

[...]

users:

• name: kubernetes-admin user: exec: apiVersion: client.authentication.k8s.io/v1beta1 command: aws-iam-authenticator args: - "token" - "-i" - "REPLACE_ME_WITH_YOUR_CLUSTER_ID" - "-r" - "REPLACE_ME_WITH_YOUR_ROLE_ARN"

  no client certificate/key needed here!

इसका मतलब है कि `kubeconfig` पूरी तरह से सार्वजनिक डेटा है और इसे सभी Authenticator उपयोगकर्ताओं के बीच साझा किया जा सकता है।
इसे किसी भरोसेमंद सार्वजनिक स्थान जैसे AWS S3 पर अपलोड करना उचित हो सकता है।

सुनिश्चित करें कि आपके पास `aws-iam-authenticator` बाइनरी इंस्टॉल है।
आप इसे `go install sigs.k8s.io/aws-iam-authenticator/cmd/aws-iam-authenticator@latest` से इंस्टॉल कर सकते हैं।

प्रमाणित करने के लिए, `kubectl --kubeconfig /path/to/kubeconfig" [...]` चलाएँ।
kubectl आपके kubeconfig में दिए गए पैरामीटरों के साथ `aws-iam-authenticator` बाइनरी को `exec` करेगा, जो एक टोकन उत्पन्न करेगा और उसे apiserver को पास करेगा।
टोकन 15 मिनट के लिए वैध होता है (सबसे छोटा मान जो AWS अनुमति देता है) और इसे कई बार पुनः उपयोग किया जा सकता है।

आप टोकन उत्पन्न करते समय `--session-name or -s` पैरामीटर शामिल करके सत्र नाम भी निर्दिष्ट कर सकते हैं। इस पैरामीटर का उपयोग `--forward-session-name` के साथ नहीं किया जा सकता।

आप किसी समर्पित भूमिका माने बिना अपने मौजूदा क्रेडेंशियल्स के साथ टोकन पर हस्ताक्षर करने के लिए `-r ROLE_ARN` को छोड़ भी सकते हैं।
यह उपयोगी है यदि आप सीधे IAM उपयोगकर्ता के रूप में प्रमाणित करना चाहते हैं या यदि आप EC2 इंस्टेंस भूमिका या फेडरेटेड भूमिका का उपयोग करके प्रमाणित करना चाहते हैं।

## Kops उपयोग
[Kops](https://github.com/kubernetes/kops) द्वारा प्रबंधित क्लस्टर को Authenticator का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है। उपयोग निर्देशों के लिए [Kops दस्तावेज़](https://kops.sigs.k8s.io/authentication/#aws-iam-authenticator) देखें।

## यह कैसे काम करता है?
यह AWS [`sts:GetCallerIdentity`](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html) API एंडपॉइंट का उपयोग करके काम करता है।
यह एंडपॉइंट उन AWS IAM क्रेडेंशियल्स के बारे में जानकारी लौटाता है जिनका उपयोग आप इससे कनेक्ट करने के लिए करते हैं।

#### क्लाइंट पक्ष (`aws-iam-authenticator token`)
हम इस API का उपयोग कुछ हद तक असामान्य तरीके से करते हैं, जिसमें Authenticator क्लाइंट एंडपॉइंट पर अनुरोध उत्पन्न और पूर्व-हस्ताक्षरित करता है।
हम उस अनुरोध को एक टोकन में क्रमबद्ध करते हैं जो Kubernetes प्रमाणीकरण प्रणाली से गुजर सकता है।

#### सर्वर पक्ष (`aws-iam-authenticator server`)
टोकन Kubernetes API सर्वर के माध्यम से और वेबहुक कॉन्फ़िगरेशन के जरिए Authenticator सर्वर के `/authenticate` एंडपॉइंट तक पहुँचाया जाता है।
Authenticator सर्वर पूर्व-हस्ताक्षरित अनुरोध के सभी मापदंडों को सत्यापित करता है ताकि यह सुनिश्चित हो सके कि कुछ भी अजीब न लगे।
फिर यह अनुरोध को वास्तविक `https://sts.amazonaws.com` सर्वर को प्रस्तुत करता है, जो क्लाइंट के HMAC हस्ताक्षर को सत्यापित करता है और उपयोगकर्ता के बारे में जानकारी लौटाता है।
अब जब सर्वर को क्लाइंट की AWS पहचान पता चल जाती है, तो यह एक सरल स्थिर मैपिंग के माध्यम से इस पहचान को Kubernetes उपयोगकर्ता और समूहों में अनुवादित करता है।

यह तंत्र कुछ बदलावों के साथ [Vault](https://www.vaultproject.io/docs/auth/aws.html#iam-auth-method) से उधार लिया गया है।

## क्लस्टर ID क्या है?
Authenticator क्लस्टर ID एक प्रति-क्लस्टर अद्वितीय पहचानकर्ता है जो कुछ रीप्ले हमलों को रोकता है।
विशेष रूप से, यह एक Authenticator सर्वर (उदाहरण के लिए, एक डेव वातावरण में) को किसी अन्य क्लस्टर में दूसरे Authenticator सर्वर के खिलाफ क्लाइंट के टोकन का उपयोग करके प्रमाणित होने से रोकता है।

क्लस्टर ID को प्रति-क्लस्टर अद्वितीय होना आवश्यक है, लेकिन इसे गुप्त रखना आवश्यक नहीं है।
कुछ अच्छे विकल्प हैं:
 - `openssl rand 16 -hex` जैसा यादृच्छिक ID
 - आपके Kubernetes API सर्वर का डोमेन नाम

[Vault दस्तावेज़](https://www.vaultproject.io/docs/auth/aws.html#iam-auth-method) भी इस हमले की व्याख्या करता है (देखें `X-Vault-AWS-IAM-Server-ID`)।

## क्रेडेंशियल्स निर्दिष्ट करना और AWS प्रोफाइल का उपयोग करना
`aws-iam-authenticator` के साथ उपयोग के लिए क्रेडेंशियल्स को [AWS SDK for Go](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials) के लिए उपलब्ध किसी भी विधि के माध्यम से निर्दिष्ट किया जा सकता है।
इसमें पर्यावरण चर के साथ AWS क्रेडेंशियल्स निर्दिष्ट करना या क्रेडेंशियल्स फ़ाइल का उपयोग करना शामिल है।

AWS [नामित प्रोफाइल](https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html) `aws-iam-authenticator` द्वारा `AWS_PROFILE` पर्यावरण चर के माध्यम से समर्थित हैं। उदाहरण के लिए, _dev_ प्रोफाइल में निर्दिष्ट क्रेडेंशियल्स के साथ प्रमाणित करने के लिए `AWS_PROFILE` को निर्यात किया जा सकता है या स्पष्ट रूप से निर्दिष्ट किया जा सकता है (जैसे, `AWS_PROFILE=dev kubectl get all`)। यदि `AWS_PROFILE` सेट नहीं है, तो _default_ प्रोफाइल का उपयोग किया जाता है।

`AWS_PROFILE` को सीधे kubeconfig फ़ाइल में भी निर्दिष्ट किया जा सकता है
[`exec` प्रवाह के भाग के रूप में](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#configuration)। उदाहरण के लिए, यह निर्दिष्ट करने के लिए
कि _dev_ नामित प्रोफाइल के क्रेडेंशियल्स का उपयोग हमेशा `aws-iam-authenticator` द्वारा किया जाना चाहिए, आपके kubeconfig में एक `env` कुंजी शामिल होगी जो प्रोफाइल सेट करती है:```yaml
apiVersion: v1
clusters:
- cluster:
    server: ${server}
    certificate-authority-data: ${cert}
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: aws
  name: aws
current-context: aws
kind: Config
preferences: {}
users:
- name: aws
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      command: aws-iam-authenticator
      env:
      - name: "AWS_PROFILE"
        value: "dev"
      args:
        - "token"
        - "-i"
        - "mycluster"

यह विधि उपयुक्त प्रोफ़ाइल को परोक्ष रूप से उपयोग करने की अनुमति देती है। ध्यान दें कि exec प्रवाह के भाग के रूप में सेट किए गए कोई भी पर्यावरण चर आपके वातावरण में पहले से सेट किए गए मानों पर वरीयता लेंगे।

फ़ेडरेटेड उपयोगकर्ताओं के लिए नोट:

फ़ेडरेटेड AWS उपयोगकर्ताओं के पास अक्सर खाते के AWS कॉन्फ़िगरेशन के माध्यम से उनकी ग्रहण की गई भूमिका पर एक "meaningful" विशेषता मैप की गई होती है, जैसे कि ईमेल पता। इन ग्रहण किए गए सत्रों में कुछ भाग होते हैं, role id और caller-specified-role-name। डिफ़ॉल्ट रूप से, जब कोई फ़ेडरेटेड उपयोगकर्ता नई भूमिका ग्रहण करने के लिए aws-iam-authenticator के --role विकल्प का उपयोग करता है, तो caller-specified-role-name को एक यादृच्छिक टोकन में बदल दिया जाएगा और role id नई ग्रहण की गई भूमिका में बना रहता है।

aws-iam-authenticator token ... --forward-session-name का उपयोग करने से मूल caller-specified-role-name विशेषता नए STS assumed session पर मैप हो जाएगी। यह त्वरित रूप से यह जोड़ने का प्रयास करने के लिए उपयोगी हो सकता है कि "K8 क्लस्टर पर क्रिया X किसने की"।

कृपया ध्यान दें, इसे निश्चित नहीं माना जाना चाहिए और इसे role id (जो सुसंगत रहता है) के माध्यम से CloudTrail लॉग्स के साथ क्रॉस-रेफरेंस किए जाने की आवश्यकता है, क्योंकि कोई उपयोगकर्ता संभावित रूप से इसे क्लाइंट पक्ष पर बदल सकता है।

क्लस्टर के बाहर से API प्राधिकरण

Kubernetes API से अनुरोध करना संभव है, ऐसे क्लाइंट से जो क्लस्टर के बाहर है, चाहे वह सीधे Kubernetes REST API या भाषा-विशिष्ट Kubernetes क्लाइंट्स में से किसी एक का उपयोग करके (जैसे, Python)। ऐसा करने के लिए, आपको एक bearer token बनाना होगा जो API को भेजे जाने वाले अनुरोध के साथ शामिल किया जाता है। इस bearer token के लिए आपको k8s-aws-v1. स्ट्रिंग के साथ एक हस्ताक्षरित HTTP अनुरोध की base64 एन्कोडेड स्ट्रिंग संलग्न करनी होती है, जो STS GetCallerIdentity Query API को भेजा जाता है। फिर इसे Authorization हेडर में भेजा जाता है। ध्यान देने वाली बात यह है कि IAM Authenticator स्पष्ट रूप से base64 पैडिंग को हटा देता है ताकि किसी भी = वर्ण से बचा जा सके, जिससे URL में उपयोग के लिए सुरक्षित स्ट्रिंग सुनिश्चित होती है। नीचे एक उदाहरण है Python में कि यह token कैसे बनाया जाएगा:```python import base64 import boto3 import re from botocore.signers import RequestSigner

def get_bearer_token(cluster_id, region): STS_TOKEN_EXPIRES_IN = 60 session = boto3.session.Session()

client = session.client('sts', region_name=region)
service_id = client.meta.service_model.service_id

signer = RequestSigner(
    service_id,
    region,
    'sts',
    'v4',
    session.get_credentials(),
    session.events
)

params = {
    'method': 'GET',
    'url': 'https://sts.{}.amazonaws.com/?Action=GetCallerIdentity&Version=2011-06-15'.format(region),
    'body': {},
    'headers': {
        'x-k8s-aws-id': cluster_id
    },
    'context': {}
}

signed_url = signer.generate_presigned_url(
    params,
    region_name=region,
    expires_in=STS_TOKEN_EXPIRES_IN,
    operation_name=''
)

base64_url = base64.urlsafe_b64encode(signed_url.encode('utf-8')).decode('utf-8')

# remove any base64 encoding padding:
return 'k8s-aws-v1.' + re.sub(r'=*', '', base64_url)

If making a HTTP request you would create the authorization headers as follows:

headers = {'Authorization': 'Bearer ' + get_bearer_token('my_cluster', 'us-east-1')}

## समस्या निवारण

यदि आपका क्लाइंट `could not get token: AccessDenied [...]` जैसी त्रुटि के साथ विफल हो जाता है, तो आप AWS CLI के साथ सीधे भूमिका ग्रहण करने का प्रयास कर सकते हैं:```sh
# AWS CLI version of `aws-iam-authenticator token -r arn:aws:iam::ACCOUNT:role/ROLE`:
$ aws sts assume-role --role-arn arn:aws:iam::ACCOUNT:role/ROLE --role-session-name test

यदि यह विफल हो जाता है, तो जाँचने के लिए कुछ संभावित समस्याएँ हैं:

• सुनिश्चित करें कि आपके आधारभूत AWS क्रेडेंशियल आपके शेल में उपलब्ध हैं (aws sts get-caller-identity इसमें समस्या निवारण में मदद कर सकता है)।

• सुनिश्चित करें कि लक्ष्य भूमिका आपके स्रोत खाते को पहुँच की अनुमति देती है (भूमिका ट्रस्ट नीति में)।

• सुनिश्चित करें कि आपके स्रोत प्रिंसिपल (उपयोगकर्ता/भूमिका/समूह) के पास एक IAM नीति है जो लक्ष्य भूमिका के लिए sts:AssumeRole की अनुमति देती है।

• सुनिश्चित करें कि आपके उपयोगकर्ता, समूह, या AWS Organizations में कोई स्पष्ट अस्वीकार नीतियाँ संलग्न नहीं हैं जो sts:AssumeRole को रोकेंगी।

• Policy Simulator में sts:AssumeRole कॉल का अनुकरण करने का प्रयास करें।

पूर्ण कॉन्फ़िगरेशन प्रारूप

क्लाइंट और सर्वर का कॉन्फ़िगरेशन प्रारूप समान है। वे एक ही सटीक कॉन्फ़िगरेशन फ़ाइल साझा कर सकते हैं, क्योंकि कॉन्फ़िगरेशन में कोई गुप्त जानकारी संग्रहीत नहीं होती है।```yaml

a unique-per-cluster identifier to prevent replay attacks (see above)

clusterID: my-dev-cluster.example.com

default IAM role to assume for aws-iam-authenticator token

defaultRole: arn:aws:iam::000000000000:role/KubernetesAdmin

server listener configuration

server:

localhost port where the server will serve the /authenticate endpoint

port: 21362 # (default)

state directory for generated TLS certificate and private keys

stateDir: /var/aws-iam-authenticator # (default)

output path where a generated webhook kubeconfig will be stored.

generateKubeconfig: /etc/kubernetes/aws-iam-authenticator.kubeconfig # (default)

role to assume before querying EC2 API in order to discover metadata like EC2 private DNS Name

ec2DescribeInstancesRoleARN: arn:aws:iam::000000000000:role/DescribeInstancesRole

AWS Account IDs to scrub from server logs. (Defaults to empty list)

scrubbedAccounts:

• "111122223333"
• "222233334444"

each mapRoles entry maps an IAM role to a username and set of groups

Each username and group can optionally contain template parameters:

1) "{{AccountID}}" is the 12 digit AWS ID.

2) "{{SessionName}}" is the role session name, with @ characters

transliterated to - characters.

3) "{{SessionNameRaw}}" is the role session name, without character

transliteration (available in version >= 0.5).

mapRoles:

statically map arn:aws:iam::000000000000:role/KubernetesAdmin to cluster admin

• rolearn: arn:aws:iam::000000000000:role/KubernetesAdmin username: kubernetes-admin groups:
  • system:masters

map EC2 instances in my "KubernetesNode" role to users like

"aws:000000000000:instance:i-0123456789abcdef0". Only use this if you

trust that the role can only be assumed by EC2 instances. If an IAM user

can assume this role directly (with sts:AssumeRole) they can control

SessionName.

• rolearn: arn:aws:iam::000000000000:role/KubernetesNode username: aws:{{AccountID}}:instance:{{SessionName}} groups:
  • system:bootstrappers
  • aws:instances

map nodes that should conform to the username "system:node:". This

requires the authenticator to query the EC2 API in order to discover the private

DNS of the EC2 instance originating the authentication request.

{{EC2PrivateDNSName}} is resolved by using the session name as an EC2 instance

ID and calling ec2:DescribeInstances. Note that if this role is assumed directly

by an IAM User (not via federation), the user can set the session name to any

instance ID, resolving another instance's private DNS and impersonating that node.

Optionally, you may specify a role that should be assumed before querying the EC2 API with the

key "server.ec2DescribeInstancesRoleARN" (see above).

• rolearn: arn:aws:iam::000000000000:role/KubernetesNode username: system:node:{{EC2PrivateDNSName}} groups:
  • system:nodes
  • system:bootstrappers

map federated users in my "KubernetesAdmin" role to users like

"admin:alice-example.com". The SessionName is an arbitrary role name

like an e-mail address passed by the identity provider. Note that if this

role is assumed directly by an IAM User (not via federation), the user

can control the SessionName.

• rolearn: arn:aws:iam::000000000000:role/KubernetesAdmin username: admin:{{SessionName}} groups:
  • system:masters

map federated users in my "KubernetesOtherAdmin" role to users like

"alice-example.com". The SessionName is an arbitrary role name

like an e-mail address passed by the identity provider. Note that if this

role is assumed directly by an IAM User (not via federation), the user

can control the SessionName. Note that the "{{SessionName}}" macro is

quoted to ensure it is properly parsed as a string.

• rolearn: arn:aws:iam::000000000000:role/KubernetesOtherAdmin username: "{{SessionName}}" groups:
  • system:masters

If unalterable identification of an IAM User is desirable, you can map against

AccessKeyID.

• rolearn: arn:aws:iam::000000000000:role/KubernetesOtherAdmin username: "admin:{{AccessKeyID}}" groups:
  • system:masters

each mapUsers entry maps an IAM user to a static username and set of groups

mapUsers:

map user IAM user Alice in 000000000000 to user "alice" in group "system:masters"

• userarn: arn:aws:iam::000000000000:user/Alice username: alice groups:
  • system:masters

automatically map IAM ARN from these accounts to username.

NOTE: Always use quotes to avoid the account numbers being recognized as numbers

instead of strings by the yaml parser.

mapAccounts:

• "012345678901"
• "456789012345"

source mappings from this file (mapUsers, mapRoles, & mapAccounts)

backendMode:

• MountedFile

## विकास

[विकास](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/HEAD/docs/development.md) पृष्ठ देखें।

## समुदाय, चर्चा, योगदान और सहायता

[सामुदायिक पृष्ठ](http://kubernetes.io/community/) पर Kubernetes समुदाय से जुड़ने का तरीका जानें।

आप इस परियोजना के अनुरक्षकों से यहाँ संपर्क कर सकते हैं:

- [Slack](https://kubernetes.slack.com/messages/sig-aws)
- [मेलिंग सूची](https://groups.google.com/forum/#!forum/kubernetes-sig-aws)

### आचार संहिता

Kubernetes समुदाय में भागीदारी [Kubernetes आचार संहिता](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/HEAD/code-of-conduct.md) द्वारा शासित है।