aws-iam-authenticator

# Kubernetes के लिए AWS IAM Authenticator

Kubernetes क्लस्टर में प्रमाणित करने के लिए AWS IAM क्रेडेंशियल्स का उपयोग करने का एक टूल।
इस टूल पर प्रारंभिक कार्य Heptio द्वारा किया गया था। यह प्रोजेक्ट कई समुदाय इंजीनियरों से योगदान प्राप्त करता है और वर्तमान में Heptio और Amazon EKS OSS Engineers द्वारा अनुरक्षित है।

## विषय-सूची

- [मुझे यह क्यों चाहिए?](#why-do-i-want-this)
- [मैं इसका उपयोग कैसे करूँ?](#how-do-i-use-it)
- [Kops उपयोग](#kops-usage)
- [यह कैसे काम करता है?](#how-does-it-work)
- [क्लस्टर ID क्या है?](#what-is-a-cluster-id)
- [क्रेडेंशियल्स निर्दिष्ट करना और AWS प्रोफ़ाइल का उपयोग करना](#specifying-credentials--using-aws-profiles)
- [क्लस्टर के बाहर से API प्राधिकरण](#api-authorization-from-outside-a-cluster)
- [समस्या निवारण](#troubleshooting)
- [पूर्ण कॉन्फ़िगरेशन प्रारूप](#full-configuration-format)
- [विकास](#development)
- [समुदाय, चर्चा, योगदान और सहायता](#community-discussion-contribution-and-support)

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

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

## मैं इसका उपयोग कैसे करूँ?
यह मानते हुए कि आपके पास AWS में एक क्लस्टर चल रहा है और आप Kubernetes समर्थन के लिए AWS IAM Authenticator जोड़ना चाहते हैं, आपको यह करना होगा:
 1. उपयोगकर्ताओं की पहचान करने के लिए उपयोग की जाने वाली एक IAM भूमिका बनाएँ।
 2. Authenticator सर्वर को DaemonSet के रूप में चलाएँ।
 3. अपने API सर्वर को Authenticator से बात करने के लिए कॉन्फ़िगर करें।
 4. kubectl को Authenticator टोकन का उपयोग करने के लिए सेट करें।

### 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'
```

आप इस चरण को छोड़ भी सकते हैं और इसका उपयोग कर सकते हैं:
 - एक मौजूदा भूमिका (जैसे क्रॉस-अकाउंट एक्सेस भूमिका)।
 - एक IAM उपयोगकर्ता (नीचे `mapUsers` देखें)।
 - एक EC2 इंस्टेंस या एक फ़ेडरेटेड भूमिका (नीचे `mapRoles` देखें)।

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

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

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

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

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

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

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

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

### 4. kubernetes उपयोगकर्ता/समूह मैपिंग के लिए IAM भूमिका/उपयोगकर्ता बनाएं
सर्वर का डिफ़ॉल्ट व्यवहार यह है कि वह मैपिंग को विशेष रूप से अपनी कॉन्फ़िगरेशन फ़ाइल के
`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` (alpha)
यह बैकएंड प्रत्येक IAM मैपिंग को एक `IAMIdentityMapping` [Kubernetes कस्टम
संसाधन](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
के रूप में मॉडल करता है। यह दृष्टिकोण आपको kubectl या API का उपयोग करके Kubernetes-मूल
तरीके से मैपिंग बनाए रखने में सक्षम बनाता है। साथ ही, सिंटैक्स त्रुटियाँ (जैसे गलत
संरेखित YAML) अधिक आसानी से पकड़ी जा सकती हैं और सभी मैपिंग को प्रभावित नहीं करेंगी।

`IAMIdentityMapping` CRD सेटअप करने के लिए आपको पहले CRD मैनिफ़ेस्ट को `apply` करना
होगा:

```
kubectl apply -f deploy/iamidentitymapping.yaml
```

CRDs तैनात होने के बाद आप Custom Resources बना सकते हैं जो आपकी
IAM Identities को मॉडल करते हैं। देखें
[`./deploy/example-iamidentitymapping.yaml`](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/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 क्लस्टर (क्लस्टरों) के अतिरिक्त 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 उपयोगकर्ता नाम के लिए आरक्षित उपसर्ग (reserved prefix) का समर्थन कर सकता है। यदि आरक्षित उपसर्ग सेट है, तो आरक्षित उपसर्ग वाले उपयोगकर्ता नाम को त्रुटि के साथ प्रमाणित नहीं किया जाएगा
"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. kubectl को Kubernetes के लिए AWS IAM Authenticator द्वारा प्रदान किए गए प्रमाणीकरण टोकन का उपयोग करने के लिए सेट करें

अंत में, एक बार सर्वर सेट हो जाने के बाद आप प्रमाणीकरण करना चाहेंगे।
आपको अभी भी एक `kubeconfig` की आवश्यकता होगी जिसमें आपके क्लस्टर के बारे में सार्वजनिक डेटा (क्लस्टर CA प्रमाणपत्र, एंडपॉइंट पता) हो।
हालाँकि, आपके कॉन्फ़िगरेशन के `users` अनुभाग में एक exec अनुभाग शामिल होना चाहिए ([kubectl क्रेडेंशियल प्लगइन दस्तावेज़ देखें](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins)):
```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 या -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 सर्वर (जैसे, किसी dev वातावरण में) को किसी अन्य क्लस्टर में किसी अन्य 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 SDK for Go](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials) के लिए उपलब्ध किसी भी विधि के माध्यम से `aws-iam-authenticator` के साथ उपयोग के लिए निर्दिष्ट किया जा सकता है।
इसमें पर्यावरण चर के साथ AWS क्रेडेंशियल निर्दिष्ट करना या किसी क्रेडेंशियल फ़ाइल का उपयोग करना शामिल है।

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

---

[Read more](https://github.com/kubernetes-sigs/aws-iam-authenticator)