KubernetesにおいてのAWSリソースのアクセス管理

はじめに

Kubernetesは、マシンを最大限に活用できるオープンソースのコンテナオーケストレーションシステムです。 ただし、Kubernetesを使用すると、さまざまなAmazon Webサービス（AWS）へのポッドのアクセスを管理するという問題が発生します。 この記事では、特定のツールを使用してこれらの問題を克服する方法について説明します。 カバーする記事の内容は次のとおりです。

• アクセスの管理が問題になる理由
• Kube2iamを介したアクセスの管理
• KIAMを介したアクセスの管理
• サービスアカウントのIAMロール（IRSA）

AWSサービスへのアクセスの管理が問題になるのはなぜなのか？

想像してみてください。Kubernetesノードは、AWSDynamoDBテーブルへのアクセスを必要とするアプリケーションポッドをホストしています。一方、同じノード上の別のポッドは、AWSS3バケットにアクセスする必要があります。両方のアプリケーションが正しく機能するには、KubernetesワーカーノードがDynamoDBテーブルとS3バケットの両方に同時にアクセスする必要があります。

ここで、これが何百ものポッドで発生し、すべてがさまざまなAWSリソースへのアクセスを必要とすることを考えてみてください。ポッドは、複数の異なるAWSサービスに同時にアクセスする必要があるGovernorateクラスターで常にスケジュールされています...これがたくさんあるのです！

これを解決する1つの方法は、Kubernetesノード（つまりポッド）にすべてのAWSリソースへのアクセスを許可することです。ただし、これにより、システムは潜在的な攻撃者の標的になりやすくなります。単一のポッドまたはノードが侵害された場合、攻撃者はAWSインフラストラクチャ全体にアクセスできるようになります。これを回避するには、Kube2iam、Kiam、IAM IRSAなどのツールを使用して、KubernetesポッドからAWSリソースへのアクセスを改善できます。すべてのアクセスAPI呼び出しと認証メトリックは、Prometheusによってプルされ、Grafanaで視覚化できます。 Prometheus / Grafanaパーツを自分で試してみたい場合は、MetricFireの[無料デモを予約}(https://www.metricfire.com/demo-japan/?utm_source=blog&utm_medium=Qiita&utm_campaign=Japan&utm_content=Kubernetes%20on%20AWS%20Resources)して、ご相談ください。

Kube2iamを使用した実装へ

全体的なアーキテクチャ

Kube2iamは、クラスターにDaemonSetとしてデプロイされます。 したがって、Kube2iamのポッドは、Kubernetesクラスターのすべてのワーカーノードで実行されるようにスケジュールされます。 別のポッドがリソースにアクセスするためにAWSAPI呼び出しを行うと、その呼び出しはそのノードで実行されているKube2iamポッドによってインターセプトされます。 次に、Kube2iamは、ポッドにリソースにアクセスするための適切な資格情報が割り当てられていることを確認します。

また、ポッド仕様でIDおよびアクセス管理（IAM）の役割を指定する必要があります。 内部的には、Kube2iamポッドは、発信者のIAMロールの一時的な資格情報を取得し、それらを発信者に返します。 基本的に、すべてのAmazon Elastic Compute Cloud（EC2）メタデータAPI呼び出しはプロキシになります。 （Kube2iamポッドは、EC2メタデータAPI呼び出しを実行できるように、ホストネットワーキングを有効にして実行する必要があります。）

実装

IAMロールの作成と添付

1. 必要なAWSリソース（たとえば、AWS S3バケット）にアクセスできるmy-roleという名前のIAMロールを作成します。
2. 次の手順に従って、ロールとKubernetesワーカーノードにアタッチされているロールの間の信頼関係を有効にします。 （Kubernetes APIワーカーに関連付けられているロールのアクセス許可が非常に制限されていることを確認してください。すべてのAPI呼び出しまたはアクセス要求は、ノードで実行されているコンテナーによって行われ、Kube2iamを使用して資格情報を受け取るため、ワーカーノードのIAMロールにアクセスする必要はありません。 多数のAWSリソース。）

a. AWSコンソールで新しく作成された役割に移動し、[Trust relationships]タブを選択します
b. [Edit Trust relationships]をクリックします
c. ポリシーに次のコンテンツを追加します。

{
  "Sid": "",
  "Effect": "Allow",
  "Principal": {
    "AWS": "<ARN_KUBERNETES_NODES_IAM_ROLE>"
  },
  "Action": "sts:AssumeRole"
}

d. ノードプールIAMロールの「Assume role」を有効にします。 次のコンテンツをノードIAMポリシーに追加します。

{
        "Sid": "",
    "Effect": "Allow",
    "Action": [
        "sts:AssumeRole"
    ],
    "Resource": [
        "arn:aws:iam::810085094893:instance-profile/*"
    ]
}

3.IAMロールの名前を注釈としてデプロイメントに追加します。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: mydeployment
  namespace: default
spec:
...
  minReadySeconds: 5
  template:
      annotations:
        iam.amazonaws.com/role: my-role
    spec:
      containers:
...

Kube2iamのデプロイ

1. Kube2iamポッドで使用するサービスアカウントClusterRoleおよびClusterRoleBindingを作成します。 ClusterRoleには、すべてのAPIグループの下にある名前名とポッドへの「get」、「watch」、および「list」アクセスが必要です。 以下のマニフェストを使用して、それらを作成できます。

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kube2iam
  namespace: kube-system
---
apiVersion: v1
kind: List
items:
  - apiVersion: rbac.authorization.k8s.io/v1beta1
    kind: ClusterRole
    metadata:
      name: kube2iam
    rules:
      - apiGroups: [""]
        resources: ["namespaces","pods"]
        verbs: ["get","watch","list"]
  - apiVersion: rbac.authorization.k8s.io/v1beta1
    kind: ClusterRoleBinding
    metadata:
      name: kube2iam
    subjects:
    - kind: ServiceAccount
      name: kube2iam
      namespace: kube-system
    roleRef:
      kind: ClusterRole
      name: kube2iam
      apiGroup: rbac.authorization.k8s.io
---

2.以下のマニフェストを使用して、Kube2iamDaemonSetをデプロイします。

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: kube2iam
  labels:
    app: kube2iam
  namespace: kube-system
spec:
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        name: kube2iam
    spec:
      hostNetwork: true
      serviceAccount: kube2iam
      containers:
        - image: jtblin/kube2iam:latest
          name: kube2iam
          args:
            - "--auto-discover-base-arn"
            - "--iptables=true"
            - "--host-ip=$(HOST_IP)"
            - "--host-interface=cali+"
            - "--verbose"
            - "--debug"
          env:
            - name: HOST_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
          ports:
            - containerPort: 8181
              hostPort: 8181
              name: http
          securityContext:
            privileged: true
---

注：Kube2iamコンテナーは、引数--iptables = trueおよび--host-ip = $（HOST_IP）を使用して、特権モードでtrueとして実行されています。

...
    securityContext:
        privileged: true
...

次の設定は、他のポッドで実行されているコンテナがEC2メタデータAPIに直接アクセスして、AWSリソースへの不要なアクセスを取得するのを防ぎます。 169.254.169.254へのトラフィックは、Dockerコンテナーのプロキシにする必要があります。 または、各Kubernetesワーカーノードで次のコマンドを実行することで、これを適用できます。

iptables \
  --append PREROUTING \
  --protocol tcp \
  --destination 169.254.169.254 \
  --dport 80 \
  --in-interface docker0 \
  --jump DNAT \
  --table nat \
--to-destination `curl 169.254.169.254/latest/meta-data/local-ipv4`:8181

テストポッドからのアクセスのテスト

Kube2iamデプロイメントとIAM設定が機能するかどうかを確認するために、アノテーションとして指定されたIAMロールを使用してテストポッドをデプロイできます。 すべてが機能する場合は、どのIAMノードがポッドに接続されているかを確認できるはずです。 これは、EC2メタデータAPIにクエリを実行することで簡単に確認できます。 以下のマニフェストを使用してテストポッドをデプロイしましょう。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: access-test
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: access-test
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: access-test
      annotations:
        iam.amazonaws.com/role: my-role
    spec:
      containers:
      - name: access-test
        image: "iotapi322/worker:v4"

作成したテストポッドで次のコマンドを実行します。

curl 169.254.169.254/latest/meta-data/iam/security-credentials/

このAPIへの応答としてmyroleを取得する必要があります。

API呼び出しがインターセプトされる方法とタイミングをより深く理解するために、そのノードで実行されているKube2iamポッドのログを調整することを強くお勧めします。 セットアップが期待どおりに機能したら、ロギングバックエンドへの攻撃を回避するために、Kube2iamデプロイメントで詳細度をオフにする必要があります。

Kiam

Kube2iamには非常に役立ちますが、Kiamが解決しようとしている2つの主要な問題があります。

1. 負荷状態でのデータ競合：アプリケーションの負荷が非常に高く、クラスター内に複数のポッドがある場合、Kube2iamがそれらのポッドに誤った資格情報を返すことがあります。 GitHubの問題はここで参照できます。

2. 事前フェッチ認証情報：コンテナがポッドでの起動を処理する前に、アクセス認証情報がポッド仕様で指定されたIAMロールに割り当てられます。 以前に資格情報を割り当てることにより、Kiamは開始待ち時間を短縮し、信頼性を向上させます。

Kiamの追加機能は次のとおりです。

• 構造化ロギングを使用して、ポッド名、ロール、アクセスキーIDなどを使用したElacsticsearch、Logstash、Kibana（ELK）セットアップへの統合を改善します。
• 応答時間、キャッシュヒット率などを追跡するためのメトリックの使用。これらのメトリックは、Prometheusによって簡単にスクレイピングされ、Grafana上にレンダリングされます。

全体的なアーキテクチャ

Kiamは、エージェントサーバーアーキテクチャに基づいています。

• Kiam Agent：これは、ポッドがAWSメタデータAPIにアクセスできないようにするために、通常はDaemonSetとしてデプロイされるプロセスです。 代わりに、Kiamエージェントは認証情報要求をインターセプトして他のすべてを渡すHTTPプロキシを実行します。
• Kiamサーバー：このプロセスは、Kubernetes APIサーバーを接続してポッドを監視し、AWS Security Token Service（STS）と通信して認証情報を要求する役割を果たします。 また、ポッドを実行することで現在使用されているロールの資格情報のキャッシュを維持し、資格情報が数分ごとに更新され、ポッドが必要になる前に保存されるようにします。

実装

Kube2iamと同様に、ポッドがIAMロールの認証情報を取得するには、そのロールをデプロイメントマニフェストのアノテーションとして指定する必要があります。 さらに、適切なアノテーションを使用して、特定の名前空間内に割り当てることができるIAMロールを指定する必要があります。 これによりセキュリティが強化され、IAMロールの制御を微調整できます。

IAMロールの作成とアタッチ

1. AWSリソースへの適切なアクセス権を持つkiam-serverという名前のIAMロールを作成します。

2. 次の手順に従って、kiam-serverロールとKubernetesマスターノードにアタッチされたロールの間のTrust relationshipsを有効にします。 （Kubernetes APIワーカーに関連付けられているロールの権限が非常に制限されていることを確認してください。すべてのAPI呼び出しまたはアクセスリクエストはノードで実行されているコンテナによって行われ、Kiamを使用して認証情報を受け取ります。ワーカーノードのIAMロールは多くのアクセス権を必要としません。 AWSリソース。）

a. AWSコンソールで新しく作成されたロールに移動し、[Trust relationships]タブを選択します。

b. [Edit Trust relationships]をクリックします。

c. 次のコンテンツをポリシーに追加します。

{
  "Sid": "",
  "Effect": "Allow",
  "Principal": {
    "AWS": "<ARN_KUBERNETES_MASTER_IAM_ROLE>"
  },
  "Action": "sts:AssumeRole"
}

3.インラインポリシーをkiam-serverロールに追加します。

{
  "Version": "2012-10-17",
  "Statement": [
   {
     "Effect": "Allow",
     "Action": [
       "sts:AssumeRole"
       ],
       "Resource": "*"
   }
 ]
}

1. AWSリソースへの適切なアクセス権を持つIAMロール（my-role）を作成します。

5.新しく作成されたロールとKiamサーバーロールの間のTrust relationshipsを有効にします。

そうするために：

a. AWSコンソールで新しく作成されたロールに移動し、[Trust relationships]を選択します

b. [Edit Trust relationships]をクリックします

c. 次のコンテンツをポリシーに追加します。

{
  "Sid": "",
  "Effect": "Allow",
  "Principal": {
    "AWS": "<ARN_KIAM-SERVER_IAM_ROLE>"
  },
  "Action": "sts:AssumeRole"
}

6.マスタープールIAMロールの「Assume role」を有効にします。 次のコンテンツをインラインポリシーとしてマスターIAMロールに追加します。

{
  "Version": "2012-10-17",
  "Statement": [
   {
     "Effect": "Allow",
     "Action": [
       "sts:AssumeRole"
       ],
       "Resource": "<ARN_KIAM-SERVER_IAM_ROLE>"
   }
 ]

Kiamエージェントとサーバー間のすべての通信はTLS暗号化されています。 これにより、セキュリティが強化されます。 これを行うには、最初にcert-managerをKubernetesクラスターにデプロイし、エージェントとサーバー間の通信用の証明書を生成する必要があります。

CertManagerの展開と証明書の生成

1.カスタムリソース定義リソースを個別にインストールします。

kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.8/deploy/manifests/00-crds.yaml

2.cert-managerの名前空間を作成します。

kubectl create namespace cert-manager

1. cert-manager名前空間にラベルを付けて、リソース検証を無効にします。

kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true

1. JetstackHelmリポジトリを追加します。

helm repo add jetstack https://charts.jetstack.io

5.ローカルHelmチャートリポジトリキャッシュを更新します。

helm repo update

6.cert-managerヘルムチャートをインストールします。

helm install --name cert-manager --namespace cert-manager --version v0.8.0 jetstack/cert-manager

KiamエージェントサーバーTLSのCA秘密鍵と自己署名証明書を生成

1.CRTファイルを生成します。

openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -subj "/CN=kiam" -out kiam.cert -days 3650 -reqexts v3_req -extensions v3_ca -out ca.crt

2.CAキーペアをシークレットとしてKubernetesに保存します。

kubectl create secret tls kiam-ca-key-pair \
  --cert=ca.crt \
  --key=ca.key \
  --namespace=cert-manager

3.クラスター発行者をデプロイし、証明書を発行します。

a. Kiam名前空間を作成します

apiVersion: v1
kind: Namespace
metadata:
  name: kiam
  annotations:
    iam.amazonaws.com/permitted: ".*"
---

b. クラスター発行者をデプロイし、証明書を発行します。

apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: kiam-ca-issuer
  namespace: kiam
spec:
  ca:
    secretName: kiam-ca-key-pair
---
apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: kiam-agent
  namespace: kiam
spec:
  secretName: kiam-agent-tls
  issuerRef:
    name: kiam-ca-issuer
    kind: ClusterIssuer
  commonName: kiam
---
apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: kiam-server
  namespace: kiam
spec:
  secretName: kiam-server-tls
  issuerRef:
    name: kiam-ca-issuer
    kind: ClusterIssuer
  commonName: kiam
  dnsNames:
  - kiam-server
  - kiam-server:443
  - localhost
  - localhost:443
  - localhost:9610
---

4.証明書が正しく発行されているかどうかをテストします。

kubectl -n kiam get secret kiam-agent-tls -o yaml
kubectl -n kiam get secret kiam-server-tls -o yaml

リソースに注釈を付ける

1.IAMロールの名前をアノテーションとしてデプロイに追加します。

apiVersion: extensions/v1beta1
 kind: Deployment
 metadata:
    name: mydeployment
    namespace: default
 spec:
 ...
    minReadySeconds: 5
    template:
        annotations:
        iam.amazonaws.com/role: my-role
    spec:
        containers:
 ... 

2.ポッドが実行される名前空間に役割注釈を追加します。 Kube2iamでこれを行う必要はありません。

apiVersion: v1
 kind: Namespace
 metadata:
    name: default
    annotations:
        iam.amazonaws.com/permitted: ".*"

デフォルトでは、ロールは許可されません。 上記の正規表現を使用してすべての役割を許可したり、名前空間ごとに特定の役割を指定したりすることもできます。

Kiamエージェントとサーバーのデプロイ

Kiamサーバー
以下のマニフェストは、以下をデプロイします。

1. Kubernetesマスターノードで実行されるKiamServer DaemonSet（上記で作成したTLSシークレットを使用するように構成します）
2. Kiamサーバーサービス
3. Kiamサーバーに必要なサービスアカウント、ClusterRoleおよびClusterRoleBinding

---
kind: ServiceAccount
apiVersion: v1
metadata:
  name: kiam-server
  namespace: kiam
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: kiam-read
rules:
- apiGroups:
  - ""
  resources:
  - namespaces
  - pods
  verbs:
  - watch
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: kiam-read
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kiam-read
subjects:
- kind: ServiceAccount
  name: kiam-server
  namespace: kiam
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: kiam-write
rules:
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - patch
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: kiam-write
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kiam-write
subjects:
- kind: ServiceAccount
  name: kiam-server
  namespace: kiam
---
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  namespace: kiam
  name: kiam-server
spec:
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: kiam
        role: server
    spec:
      tolerations:
       - key: node-role.kubernetes.io/master
         effect: NoSchedule
      serviceAccountName: kiam-server
      nodeSelector:
        kubernetes.io/role: master
      volumes:
        - name: ssl-certs
          hostPath:
      nodeSelector:
      nodeSelector:
        kubernetes.io/role: master
      volumes:
        - name: ssl-certs
          hostPath:
            path: /etc/ssl/certs
        - name: tls
          secret:
            secretName: kiam-server-tls
      containers:
        - name: kiam
          image: quay.io/uswitch/kiam:b07549acf880e3a064e6679f7147d34738a8b789
          imagePullPolicy: Always
          command:
            - /kiam
          args:
            - server
            - --level=info
            - --bind=0.0.0.0:443
            - --cert=/etc/kiam/tls/tls.crt
            - --key=/etc/kiam/tls/tls.key
            - --ca=/etc/kiam/tls/ca.crt
            - --role-base-arn-autodetect
            - --assume-role-arn=<KIAM_SERVER_ROLE_ARN>
            - --sync=1m
          volumeMounts:
            - mountPath: /etc/ssl/certs
              name: ssl-certs
            - mountPath: /etc/kiam/tls
              name: tls
          livenessProbe:
            exec:
              command:
              - /kiam
              - health
              - --cert=/etc/kiam/tls/tls.crt
              - --key=/etc/kiam/tls/tls.key
              - --ca=/etc/kiam/tls/ca.crt
              - --server-address=localhost:443
              - --gateway-timeout-creation=1s
              - --timeout=5s
            initialDelaySeconds: 10
            periodSeconds: 10
            timeoutSeconds: 10
          readinessProbe:
            exec:
              command:
              - /kiam
              - health
              - --cert=/etc/kiam/tls/tls.crt
              - --key=/etc/kiam/tls/tls.key
              - --ca=/etc/kiam/tls/ca.crt
              - --server-address=localhost:443
              - --gateway-timeout-creation=1s
              - --timeout=5s
            initialDelaySeconds: 3
            periodSeconds: 10
            timeoutSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: kiam-server
  namespace: kiam
spec:
  clusterIP: None
  selector:
    app: kiam
    role: server
  ports:
  - name: grpclb
    port: 443
    targetPort: 443
    protocol: TCP

注意：

ここに配置されているスケジューラー許容値とノードセレクターは、KiamポッドがKiamマスターノードでのみスケジュールされるようにします。 これが、KiamサーバーのIAMロールとKubernetesマスターノードにアタッチされたIAMロール（上記）の間の信頼関係を有効にする理由です。

...
       tolerations:
       - key: node-role.kubernetes.io/master
         effect: NoSchedule 
...

...
      nodeSelector:
        kubernetes.io/role: master
....

1. kiam-serverロールARNは、Kiamサーバーコンテナーへの引数として提供されます。 上記のマニフェストのフィールドを、作成したロールのARNに更新してください。

2. Kiamサーバー用に作成されたClusterRoleとClusterRoleBindingは、効果的に動作するために必要な最小限のアクセス許可をサーバーに付与します。 変更する前によく検討してください。

3. cert-manager証明書を使用して作成したシークレットに従って、SSL証明書へのパスが正しく設定されていることを確認してください。 これは、KiamサーバーとKiamエージェントポッド間の安全な通信を確立するために重要です。

Kiam Agent

以下に示すマニフェストは、Kubernetesワーカーノードでのみ実行される次のKiam AgentDaemonSetをデプロイします。

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  namespace: kiam
  name: kiam-agent
spec:
  template:
    metadata:
      labels:
        app: kiam
        role: agent
    spec:
      hostNetwork: true
      dnsPolicy: ClusterFirstWithHostNet
      volumes:
        - name: ssl-certs
          hostPath:
            path: /etc/ssl/certs
        - name: tls
          secret:
            secretName: kiam-agent-tls
        - name: xtables
          hostPath:
            path: /run/xtables.lock
            type: FileOrCreate
      containers:
        - name: kiam
          securityContext:
            capabilities:
              add: ["NET_ADMIN"]
          image: quay.io/uswitch/kiam:b07549acf880e3a064e6679f7147d34738a8b789
          imagePullPolicy: Always
          command:
            - /kiam
          args:
            - agent
            - --iptables
            - --host-interface=cali+
            - --json-log
            - --port=8181
            - --cert=/etc/kiam/tls/tls.crt
            - --key=/etc/kiam/tls/tls.key
            - --ca=/etc/kiam/tls/ca.crt
            - --server-address=kiam-server:443
            - --gateway-timeout-creation=30s
          env:
            - name: HOST_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
          volumeMounts:
            - mountPath: /etc/ssl/certs
              name: ssl-certs
            - mountPath: /etc/kiam/tls
              name: tls
            - mountPath: /var/run/xtables.lock
              name: xtables
          livenessProbe:
            httpGet:
              path: /ping
              port: 8181
            initialDelaySeconds: 3
            periodSeconds: 3

Kiamエージェントも、Kube2iamと同様に、ホストネットワークをtrueに設定して実行されることに注意してください。 また、Kiamエージェントのコンテナに対する引数の1つは、KiamサーバーにアクセスするためのKiamサービスの名前です（この場合はkiam-server：443）。したがって、Kiamエージェントをデプロイする前にKiamサーバーをデプロイする必要があります。

また、コンテナ引数--gateway-timeout-creationは、エージェントが接続を試行する前にKiamサーバーポッドが起動するまでの待機期間を定義します。 ポッドがKubernetesクラスターに表示されるまでにかかる時間に応じて調整できます。 理想的には、30秒の待機期間で十分です。

テスト

KiamとKube2iamのセットアップをテストするプロセスは同じです。 テストポッドを使用してメタデータをカールし、割り当てられた役割を確認できます。 デプロイメントと名前空間の両方に適切な注釈が付けられていることを確認してください。

サービスアカウントのIAMロール（IRSA）

最近、AWSは、ポッドがAWSリソースにアクセスできるようにする独自のサービスをリリースしました。サービスアカウントのIAMロール（IRSA）です。 ロールはサービスアカウントで認証されるため、そのサービスアカウントが接続されているすべてのポッドで共有できます。 このサービスは、AWSEKSとKOPSベースのインストールの両方で利用できます。 あなたはそれについては、こちらをご確認ください。

まとめ

このブログで取り上げているツールは、KubernetesポッドからAWSリソースへのアクセスを管理するのに役立ち、すべてに長所と短所があります。

Kube2IAMは実装が最も簡単ですが、セットアップが簡単なため効率が低下し、高負荷状態では確実に動作しない可能性があります。大きなトラフィックサージが発生しない非本番環境またはシナリオに適しています。

IAM IRSAはKube2iamよりも多くの作業を必要としますが、Amazonの詳細なドキュメントを考えると、実装が簡単な場合があります。非常に最近であるため、この記事の執筆時点では、業界でIRSAの実装が十分ではありません。

KIAMの実装では、cert-managerを実行する必要があり、Kube2iamとは異なり、デプロイメントとともに名前空間に注釈を付ける必要があります。とにかく、Kiamを使用することを強くお勧めします。これは、証明書マネージャーを実行するためのリソースがあり、マスターノードがそれらで実行されているDaemonSetを処理できるようになっている場合にすべての場合に使用できるためです。この投稿で提供されているマニフェストを使用することで、セットアップがシームレスになり、本番環境に対応できるようになります。

Prometheusを搭載したGrafanaダッシュボードでメトリックを視覚化してみたい場合は、今すぐMetricFireのデモにサインアップして、どの監視ソリューションが効果的かについて直接お問い合わせください。

それでは、またの記事で！