スキップしてコンテンツを表示

Amazon EKS API サーバーに接続したときに表示される「サーバーにログインする必要があります (不正) というエラーを解決する方法を教えてください。

所要時間4分
0

kubectl コマンドを使用して Amazon Elastic Kubernetes サービス (Amazon EKS) API サーバーに接続します。「エラー: サーバーへのログインが必要です (不正)」というメッセージが表示されました。

簡単な説明

このエラーは、kubectl に設定されている AWS Identity and Access Management (IAM) エンティティが Amazon EKS によって認証されていない場合に発生します。Amazon EKS クラスターへのアクセスは、使用する IAM エンティティ (ユーザーまたはロール) に基づいて、認証され、承認されます。このエラーは通常、次のいずれかの構成が原因で発生します。

  • IAM ユーザーまたはロールを使用するように kubectl ツールを設定した。
  • IAM エンティティを aws-auth ConfigMap にマッピングした。

この問題を解決するには、ユースケースに応じて以下のいずれかのセクションの手順を完了する必要があります:

解決策

**注:**AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI エラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

クラスター作成者の場合

あなたの IAM エンティティが Amazon EKS クラスターの作成に使用された場合は、あなたがクラスター作成者です。クラスター作成者としてエラーを解決するには、次の手順を実行します。

  1. Amazon CloudWatch Log Insightsで Amazon EKS クラスターのロググループを選択します。たとえば、/aws/eks/my-cluster/clusterです。次のクエリを実行します。

    fields @logstream, @timestamp, @message| sort @timestamp desc
    | filter @logStream like /authenticator/
    | filter @message like "username=kubernetes-admin"
    | limit 50

    注: Amazon EKS の認証ログを有効にします。
    このクエリは、クラスター作成者としてマッピングされた IAM エンティティを返します:

    @messagetime="2022-05-26T18:55:30Z" level=info msg="access granted" arn="arn:aws:iam::123456789000:user/testuser" client="127.0.0.1:57586" groups="[system:masters]" method=POST path=/authenticate uid="aws-iam-authenticator:123456789000:AROAFFXXXXXXXXXX" username=kubernetes-admin
  2. AWS CLI のクラスター作成者の IAM エンティティを確認します。IAM エンティティがシェル環境で AWS CLI 用に設定されているかどうかを確認するには、次のコマンドを実行します:

    $ aws sts get-caller-identity

    特定のプロファイルを使用してこのコマンドを実行することもできます。

    $ aws sts get-caller-identity --profile MY-PROFILE

    出力では、AWS CLI 用に設定された IAM エンティティの Amazon リソースネーム (ARN) が返されます。
    例:

    {
        "UserId": "XXXXXXXXXXXXXXXXXXXXX",
        "Account": "XXXXXXXXXXXX",
        "Arn": "arn:aws:iam::XXXXXXXXXXXX:user/testuser"
    }

    返された IAM エンティティがクラスター作成者の IAM エンティティと一致することを確認します。返された IAM エンティティがクラスター作成者でない場合は、クラスター作成者の IAM エンティティを使用するように AWS CLI 設定を更新します。

  3. kubeconfig ファイルを更新するか、生成するには、次のコマンドを実行します。

    $ aws eks update-kubeconfig --name eks-cluster-name --region aws-region

    **注:**eks-cluster-name は、使用しているクラスターの名前に置き換えます。aws-region は、使用している AWS リージョンの名前に置き換えます。
    **kubeconfig ** ファイルの AWS CLI プロファイルを指定するには、次のコマンドを実行します。

    $ aws eks update-kubeconfig --name eks-cluster-name --region aws-region --profile my-profile

    **注:**eks-cluster-name は、使用しているクラスターの名前に置き換えます。aws-region は、使用しているリージョンの名前に置き換えます。my-profile は、使用しているプロファイルの名前に置き換えます。

  4. 次のコマンドを実行して、**kubeconfig ** ファイルが更新されたことを確認します。

    $ kubectl config view --minify
  5. 次のコマンドを実行して、IAM エンティティが認証され、EKS クラスターにアクセスできることを確認します。

    $ kubectl get svc

    出力例:

    NAME            TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
    kubernetes      ClusterIP   10.100.0.1     <none>        443/TCP   77d

クラスター作成者ではない場合

あなたの IAM エンティティがクラスターの作成に使用されなかった場合、あなたはクラスターの作成者ではありません。この場合、以下の手順を実行して IAM エンティティを aws-auth ConfigMap にマッピングし、クラスターへのアクセスを許可してください。

  1. AWS CLI のクラスター作成者の IAM エンティティを確認します。シェル環境で AWS CLI 用に設定された IAM エンティティを確認するには、次のコマンドを実行します。

    $ aws sts get-caller-identity

    特定のプロファイルを使用してこのコマンドを実行することもできます。

    $ aws sts get-caller-identity --profile my-profile

    出力で、AWS CLI 用に設定された IAM エンティティの ARN が返ります。
    例:

    {
        "UserId": "XXXXXXXXXXXXXXXXXXXXX",
        "Account": "XXXXXXXXXXXX",
        "Arn": "arn:aws:iam::XXXXXXXXXXXX:user/testuser"
    }

    返された IAM エンティティがクラスター作成者の IAM エンティティと一致することを確認します。返された IAM エンティティがクラスター作成者でない場合は、クラスター作成者の IAM エンティティを使用するように AWS CLI 設定を更新します。次に、kubectl を使用してクラスターへのアクセスを再試行します。問題が引き続き発生する場合は、次のステップに進んでください。

  2. 返された IAM エンティティがクラスター作成者でない場合は、エンティティを aws-auth ConfigMap に追加して、エンティティがクラスターにアクセスできるようにします。クラスター管理者のみが aws-auth ConfigMap を変更できるため、次のタスクのいずれかを実行してください。
    クラスター作成者の IAM エンティティを使用してクラスターにアクセスするには、「クラスター作成者」セクションの手順を実行します。
    クラスター管理者にこのアクションの実行を依頼してください。

  3. 次のコマンドを実行して、IAM エンティティが aws-auth ConfigMap にあるかどうかを確認してください。

    eksctl get iamidentitymapping --cluster cluster-name

    または、

    kubectl describe configmap aws-auth -n kube-system

    IAM エンティティが aws-auth ConfigMap にある場合は、次のステップに進んでください。IAM エンティティが aws-auth ConfigMap にない場合は、次のコマンドを実行して IAM エンティティを自動的にマッピングします。

    eksctl create iamidentitymapping \
        --cluster $CLUSTER-NAME \
        --region $REGION \
        --arn arn:aws:iam::XXXXXXXXXXXX:user/testuser \
        --group system:masters \
        --no-duplicate-arns \
        --username admin-user1

    または、aws-auth ConfigMap を編集して IAM エンティティを手動でマッピングすることもできます。

    $ kubectl edit configmap aws-auth -namespace kube-system

    IAM エンティティを aws-auth ConfigMap に追加するには、IAM ユーザーまたはロールの ARN を mapUsers に追加します。
    IAM ユーザーの例:

    mapUsers: |
      - userarn: arn:aws:iam::XXXXXXXXXXXX:user/testuser
        username: testuser
        groups:
          - system:masters

    IAM ロールの例:

    mapRoles: |
      - rolearn: arn:aws:iam::XXXXXXXXXXXX:role/testrole
        username: testrole
        groups:
          - system:masters

    重要:
    IAM ロールはパスなしでマッピングしてください。rolearn のパス要件の詳細については、「aws-auth ConfigMap でクラスターセクションへのアクセスが許可されない」を参照してください。
    AWS IAM Identity Center の IAM ロールに rolearn を指定するには、ロールの ARN からパス /aws-reserved/sso.amazonaws.com/REGION を削除します。そうしないと、ConfigMap のエントリで有効なユーザーとして承認されません。
    system:masters グループでは、任意のリソースに任意のアクションを実行するためのスーパーユーザーアクセスが許可されます。詳細については、Kubernetes のウェブサイトで「デフォルトのロールとロールバインディング」を参照してください。このユーザーのアクセスを制限するには、Amazon EKS ロールとロールバインディングリソースを作成します。詳細については、「必要な権限」を参照してください。

  4. 次のコマンドを使用して、kubeconfig ファイルを更新するか、生成します。AWS CLI が IAM エンティティで設定されていることを確認します。

    $ aws eks update-kubeconfig --name eks-cluster-name --region aws-region

    **注:**eks-cluster-name は、使用しているクラスターの名前に置き換えます。aws-region は、使用しているリージョンの名前に置き換えます。
    特定のプロファイルを使用してこのコマンドを実行することもできます。

    $ aws eks update-kubeconfig --name eks-cluster-name --region aws-region --profile my-profile

    **注:**eks-cluster-name は、使用しているクラスターの名前に置き換えます。aws-region は、使用しているリージョンの名前に置き換えます。my-profile は、使用しているプロファイルの名前に置き換えます。

  5. 次のコマンドを実行して、**kubeconfig ** ファイルが更新されたことを確認します。

    $ kubectl config view --minify
  6. IAM ユーザーまたはロールが認証されたことを確認するには、クラスターに再度アクセスします。たとえば、次のコマンドを実行すれば、エラーが解決されたことを確認できます。

    $ kubectl get svc

    出力例:

    NAME            TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
    kubernetes      ClusterIP   10.100.0.1     <none>        443/TCP   77d

アクセスエントリを使用してクラスターへのアクセスを回復する

CreateAccessEntry API を使用して Amazon EKS クラスターへのアクセスを付与または回復します。詳細については、「Amazon EKS アクセスエントリ API を使用して EKS クラスターへのアクセスを回復する方法を教えてください」を参照してください。

トラブルシューティング

kubectl コマンドを実行すると、リクエストが Amazon EKS クラスター API サーバーに送信されます。次に、Amazon EKS 認証システムで、このリクエストの認証が試みられます。Amazon EKS 認証システムがリクエストを認証できない場合は、CloudWatch の EKS 認証ログを確認してください。次のトラブルシューティングのヒントを参考にして問題を特定してください。

**EKS 認証ログにアクセスする **

  1. Amazon EKS クラスターのログ記録を有効にします
  2. CloudWatch Logs Insights を開きます。
  3. クラスターのロググループを選択します。例:「/aws/eks/example-cluster/cluster」。
  4. 次のクエリを実行します。
    fields @timestamp, @message| filter @logStream like /authenticator/
    | sort @timestamp desc
    | limit 1000
    エラーが発生したときと同じ時間間隔のログ行を特定するために、kubectl コマンドを実行します。

**EKS 認証ログを確認する **

エラーの原因に基づいて、次のタスクを実行します。

  • 正しくない IAM エンティティを kubectl に使用しているのが問題の原因である場合は、kubectl kubeconfig と AWS CLI の設定を確認してください。必ず正しい IAM エンティティを使用してください。次の出力例では、kubectl が使用した IAM エンティティは検証できません。kubectl が使用する IAM エンティティを確認し、そのエンティティが IAM に存在し、エンティティのプログラムによるアクセスが有効になっていることを確認します。
    出力例:

    time="2022-12-26T20:46:48Z" level=warning msg="access denied" client="127.0.0.1:43440" error="sts getCallerIdentity failed: error from AWS (expected 200, got 403). Body: {\"Error\":{\"Code\":\"InvalidClientTokenId\",\"Message\":\"The security token included in the request is invalid.\",\"Type\":\"Sender\"},\"RequestId\":\"a9068247-f1ab-47ef-b1b1-cda46a27be0e\"}" method=POST path=/authenticate
  • IAM エンティティが aws-auth ConfigMap にマッピングされていないか、マッピングが不適切であることが問題の原因の場合は、aws-auth ConfigMap を確認してください。IAM エンティティが正しくマッピングされ、「クラスター作成者ではない場合」セクションに記載されている要件を満たしていることを確認してください。IAM エンティティが誤ってマッピングされているか、見つからない場合、EKS 認証ログは次の出力例のようになります。

    time="2022-12-28T15:37:19Z" level=warning msg="access denied" arn="arn:aws:iam::XXXXXXXXXX:role/admin-test-role" client="127.0.0.1:33384" error="ARN is not mapped" method=POST path=/authenticate
  • aws-auth ConfigMap が更新されて、クラスターにアクセスできなくなった場合は、クラスター作成者の IAM エンティティを使用して、クラスターにアクセスします。クラスター作成者を aws-auth ConfigMap にマッピングする必要がないため、この IAM エンティティを使用してクラスターにアクセスしてください。

  • クラスター作成者の IAM エンティティが削除された場合は、同じ命名規則を使用して同じ IAM エンティティを再作成します。そうすれば、この再作成されたクラスター作成者の IAM エンティティは、IAM エンティティと同じ ARN を持つことができます。次に、「クラスター作成者」セクションの手順に従って、IAM エンティティを使用してクラスターにアクセスします。

  • クラスター作成者が、削除された SSO ユーザー用に作成された IAM ロールの場合、この IAM ロールは再度作成することはできません。その場合は、AWS サポートにお問い合わせください。

関連情報

Amazon EKS でクラスターを作成した後、他の IAM ユーザーやロールにアクセス許可を付与するにはどうすればよいですか?

Using RBAC authorization (Kubernetes ウェブサイト)

EKS アクセスエントリを使用して IAM ユーザーに Kubernetes へのアクセス権を付与する

EKS アクセスエントリ (eksctl のウェブサイト)

コメントはありません

関連するコンテンツ