LoginSignup
0
0
お題は不問！Qiita Engineer Festa 2024で記事投稿！
Qiita Engineer Festa20242024年7月17日まで開催中！
@triple321jhango(カイリーー)

EKSクラスターへのアクセス制御方法について(EKS API / ConfigMap)

Last updated at Posted at 2024-07-01

はじめに

実務においてEKSクラスターへのアクセス制御について理解が浅いと感じたため、深堀りしていこうと思います。

EKSクラスターへのアクセス制御についてはConfigMapとEKS APIという二つの方法が存在します。
2023年12月18日のアップデートがあるまではConfigMapによる制御のみでした。
しかし、アップデートしたことにより、より簡素化されたEKS APIという方式でKubernetesクラスターへアクセスできることとなりました。

このConfigMapとEKS APIの違いについてまとめた上でEKS APIのアクセスについて解説します。

結論

いきなり結論です。

ConfigMap

AWS IAMユーザまたはロールとKubernetes上のユーザやグループとマッピングを行い、EKSクラスターからEKSリソースへのアクセスをする必要がある。

EKS API

AWSのIAMユーザやロールに対してKubernetesの権限を設定することができる。

ConfigMapとEKS APIの違いについて

ConfigMapとは

Kubernetes APIにアクセスするための認証/認可ではaws-authを使用し、AWSのIAMユーザやロールとKubernetesのユーザやロールをマッピングして権限設定する必要があります。
図で表すと以下のようになります。
image.png

  1. AWS IAMユーザまたはロールがkubeconfigファイルを使用してEKSで稼働しているkube-apiserverへリクエスト
  2. kube-apiserverはリクエストを処理する前にリクエストしてきたユーザやロールを認可する前に、kube-systemのネームスペースに存在するaws-authConfigMapを参照
  3. ConfigMapに基づいて、IAMユーザまたはロールをKubernetesのユーザやグループにマッピング
  4. マッピングされたKubernetesユーザやグループが適用され、kube-apiserverがリクエストに対して適切な権限を確認し、AWS リソースへの操作を実行

EKS APIとは

AWSで以下4つの権限を用意しており、これらの権限をIAMユーザまたはロールにアタッチすることで、EKSクラスターへのアクセスを制御します。

  • AmazonEKSClusterAdminPolicy (EKSサービスそのもののリソースに対する管理権限: EKSクラスターの作成、更新、削除、クラスターに関連するIAMロールやポリシーの管理、EKSサービスに関連する他のAWSリソースの管理が可能となる)
  • AmazonEKSAdminPolicy (EKSクラスター内部での管理者権限に相当し、全てのネームスペースでのリソース作成、更新、削除、クラスター設定の変更、リソースの追加及び削除などが可能となる)
  • AmazonEKSEditPolicy
  • AmazonEKSViewPolicy

image.png

動作確認

クラスター構築準備

Amazon Linux2023のAMIを使用したEC2インスタンスを起動し、EKSクラスターを作成します。
※EC2インスタンスの作成方法については省略します。

以下のAWS公式ドキュメントを参照しながらeksctl1をダウンロードします。

1.eksctlの最新リリースをダウンロードする

bash
$ curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp

2.ダウンロードしたバイナリを/usr/local/binに移動する

bash
$ sudo mv /tmp/eksctl /usr/local/bin

3.ダウンロード確認

bash
$ eksctl version

4.kubectlインストール (https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/install-kubectl.html)

bash
$ curl -Ohttps://s3.us-west-2.amazonaws.com/amazon-eks/1.30.0/2024-05-12/bin/linux/amd64/kubectl.sha256

5.チェックサム確認

bash
$ sha256sum -c kubectl.sha256

6.バイナリへの実行アクセスを許可する

bash
$ chmod +x ./kubectl

7.バイナリをPATHのフォルダにコピーする

bash
$ mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$HOME/bin:$PATH

8.シェルを開いたときに設定されるようにシェルの初期化ファイルに$HOME/binパスを追加

bash
$ echo 'export PATH=$HOME/bin:$PATH' >> ~/.bashrc

9.以下yamlファイルでクラスターを作成する (既存VPCおよびサブネットを指定しないとVPC, Subnetなど全てゼロから構築されてしまうため、自身で使用しているVPCやサブネットを使用する場合には明示的に指定します)

bash
$ eksctl create cluster -f cluster.yml
sandbox-cluster.yml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: sandbox-cluster
  region: ap-northeast-1

vpc:
  id: vpc-xxxxxxxxxxxxxxx # 自身のVPC IDに置き換えてください
  subnets:
    private:
      ap-northeast-1a:
        id: subnet-xxxxxxxxxxxxxxx # 自身のサブネットIDに置き換えてください
      ap-northeast-1c:
        id: subnet-xxxxxxxxxxxxxxx # 自身のサブネットIDに置き換えてください

fargateProfiles:
  - name: fp-default
    selectors:
      - namespace: default
      - namespace: kube-system

10.kubeconfigファイルを作成し、EKSクラスターとのやり取りをできるようにする

bash
$ aws eks update-kubeconfig --region ap-northeast-1 --name sandbox-cluster

kubeconfigは~/.kube/configに作成されます。

クラスター構築後

クラスター構築後のアクセスポリシーを確認してみます。

image.png

eksctl-sandbox-cluster-clus-FargatePodExecutionRoleはEKSが自動的に作成したIAMロールです。
このロールはEKS Fargate Podがクラスター内で実行される際に使用されるIAMロールで、PodがECRからコンテナイメージを取得したり、その他のAWSサービスにアクセスしたりするための権限です。

AdministratorのプリンシパルにはAmazonEKSClusterAdminPolicyがアタッチされ、EKSクラスター内の管理者権限が付与されます。

ただし、このままではEKSクラスターとはまだやりとりできません。
冒頭で説明したように、EKSクラスターのAPIにリクエストを送る際にはkubeconfigファイルを作成し、kubeconfigファイルを使用してリクエストする必要があります。

再掲
image.png

試しに、kubeconfigファイルを作成しない状態でkubectlコマンドでEKSクラスター(kube-apiserver)へリクエストを投げてみましょう。

kubectl
$ kubectl get nodes

E0701 05:46:57.542348    4454 memcache.go:265] couldn't get current server API group list: Get "https://D7D0E33219BB97104A4A840CB72A87DD.gr7.ap-northeast-1.eks.amazonaws.com/api?timeout=32s": dial tcp: lookup D7D0E33219BB97104A4A840CB72A87DD.gr7.ap-northeast-1.eks.amazonaws.com on 10.0.0.2:53: no such host
E0701 05:46:57.544274    4454 memcache.go:265] couldn't get current server API group list: Get "https://D7D0E33219BB97104A4A840CB72A87DD.gr7.ap-northeast-1.eks.amazonaws.com/api?timeout=32s": dial tcp: lookup D7D0E33219BB97104A4A840CB72A87DD.gr7.ap-northeast-1.eks.amazonaws.com on 10.0.0.2:53: no such host
E0701 05:46:57.545485    4454 memcache.go:265] couldn't get current server API group list: Get "https://D7D0E33219BB97104A4A840CB72A87DD.gr7.ap-northeast-1.eks.amazonaws.com/api?timeout=32s": dial tcp: lookup D7D0E33219BB97104A4A840CB72A87DD.gr7.ap-northeast-1.eks.amazonaws.com on 10.0.0.2:53: no such host
E0701 05:46:57.546774    4454 memcache.go:265] couldn't get current server API group list: Get "https://D7D0E33219BB97104A4A840CB72A87DD.gr7.ap-northeast-1.eks.amazonaws.com/api?timeout=32s": dial tcp: lookup D7D0E33219BB97104A4A840CB72A87DD.gr7.ap-northeast-1.eks.amazonaws.com on 10.0.0.2:53: no such host
E0701 05:46:57.548003    4454 memcache.go:265] couldn't get current server API group list: Get "https://D7D0E33219BB97104A4A840CB72A87DD.gr7.ap-northeast-1.eks.amazonaws.com/api?timeout=32s": dial tcp: lookup D7D0E33219BB97104A4A840CB72A87DD.gr7.ap-northeast-1.eks.amazonaws.com on 10.0.0.2:53: no such host
Unable to connect to the server: dial tcp: lookup D7D0E33219BB97104A4A840CB72A87DD.gr7.ap-northeast-1.eks.amazonaws.com on 10.0.0.2:53: no such host

上記のように"サーバーに接続できません"といったエラーが返されます。

kubeconfigファイルを作成して再度アクセスしてみます。

awscli
# kubeconfigファイルの作成
# 以下AWS CLIコマンドでKubernetes Configファイルを作成
$ aws eks update-kubeconfig --name <cluster_name> --region <region>

Updated context arn:aws:eks:ap-northeast-1:{AccountID}:cluster/sandbox-cluster in /home/ec2-user/.kube/config

# 再度アクセスしてみます
$ kubectl get nodes
# リクエストに対するレスポンスが返ってきました -> 現状Nodeを作成しているわけではないので"No resorces found"となります
No resources found

kubeconfigファイルを作成すると~/.kube配下にconfigファイルが作成され、認証情報が登録されます。

$ cat ~/.kube/config

一部マスクしますが、certificate-authority-data以下に記載されている(マスクしている箇所)箇所がKubernetesクラスターのAPIサーバ(kube-apiserver)にアクセスする際のサーバ証明書を検証するためのCA証明書情報です。
image.png

EKSクラスターを作成したIAMユーザ以外をアクセスエントリに追加する場合

クラスターの[アクセス]タブから[アクセスエントリの作成]ボタンをクリックします。
image.png

IAMプリンシパルに登録したいIAMプリンシパルARNを選択します。
ユーザが利用するIAMプリンシパルにはタイプを[スタンダード]に設定します。
image.png

ユーザ名については自動生成が推奨のため空白のままにします。
image.png

アクセスポリシーを追加 - オプションでポリシー名[AmazonEKSClusterAdminPolicy] (EKSクラスターを作成したIAMユーザと同じポリシー)を追加
image.png

これでポリシーの追加が追加されます。

AWS CLIでアクセスエントリーに追加されたことを確認します。

aws cli
$ aws eks list-access-entries --cluster-name sandbox-cluster
{
    "accessEntries": [
        "arn:aws:iam::xxxxxxxxxxxx:role/eksctl-sandbox-cluster-clus-FargatePodExecutionRole-dMNVotqRuHbj",
        "arn:aws:iam::xxxxxxxxxxxx:user/Administrator",
        "arn:aws:iam::xxxxxxxxxxxx:user/develop-user"
    ]
}

クラスターの削除

諸々確認が終わり、もうクラスターは必要ないという場合には以下のコマンドでクラスターの削除をすることができます。

bash
$ eksctl delete cluster --name <clustername>

最後に

今回はEKSクラスターへのアクセスEKS API/ConfigMapについての違いを理解し、EKS APIによるアクセスを行ってみました。
本記事内ではEKSクラスターを作成したユーザにおけるEKSクラスターのアクセスについての検証ができませんでしたが、別途機会を設けて試してみたいと思っています。

  1. EKS専用のコマンドラインツールであり、EKSクラスターを構築することができます。 ↩

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0