Go to Qiita Advent Calendar 2024 Top
LoginSignup
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

@MetricFire(MetricFire Japan)

AWSサービスを利用した際、Kubenetesで起こりうるアクセス管理の問題への対処方法

Posted at

image.png

#はじめに
Kubernetesは、マシンを最大限に活用できるオープンソースのコンテナオーケストレーションシステムです。 ただし、Kubernetesを使用すると、ポッドのさまざまなAWSへのアクセスを管理する際に問題が発生します。 この記事では、特定のツールを使用した際のこれらの問題を解決する方法について説明します。 情報を整理する方法は次のとおりです。

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

#AWSサービスへのアクセスの管理が問題になるのはなぜなのか？
想像してみてください。Kubernetesノードは、AWS DynamoDBテーブルへのアクセスを必要とするアプリケーションポッドをホストしています。一方、同じノード上の別のポッドは、AWS S3バケットにアクセスする必要があります。両方のアプリケーションが正しく動作するためには、KubernetesワーカーノードがDynamoDBテーブルとS3バケットの両方に同時にアクセスする必要があります。

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

これを解決する1つの方法は、Kubernetesノード、つまりポッドにすべてのAWSリソースへのアクセスを許可することです。ただし、これによりシステムは潜在的な攻撃者の標的となることを意味します。単一のポッドまたはノードが侵害された場合、攻撃者はAWSインフラストラクチャ全体にアクセスできます。これを回避するには、Kube2iam、Kiam、IAM IRSAなどのツールを使用して、KubernetesポッドからAWSリソースへのアクセスを改善します。最良の部分？すべてのアクセスAPI呼び出しと認証メトリックは、Prometheusによってプルされ、Grafanaで視覚化できます。 Prometheus / Grafanaパーツを自分で試したい場合は、MetricFireの無料トライアルにアクセスして、ご使用を開始してみてください。

#Kube2iamを使用した実装に飛び込む

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

また、ポッド仕様でIdentity and Access Management（IAM）ロールを指定する必要があります。 内部では、Kube2iamポッドが呼び出し元のIAMロールの一時的な認証情報を取得し、それらを呼び出し元に返します。 基本的に、すべてのAmazon Elastic Compute Cloud（EC2）メタデータAPI呼び出しはプロキシになされます。 （Kube2iamポッドは、EC2メタデータAPI呼び出しを行えるように、ホストネットワークを有効にして実行する必要があります。）

####実装
IAMロールの作成とアタッチ
必要なAWSリソース（AWS S3バケットなど）にアクセスできるmy-roleという名前のIAMロールを作成します。
次の手順に従って、役割とKubernetesワーカーノードに接続されている役割との間の信頼関係を有効にします。 （Kubernetes APIワーカーにアタッチされた役割には非常に制限された権限があることを確認してください。すべてのAPI呼び出しまたはアクセスリクエストはノードで実行されているコンテナによって行われ、Kube2iamを使用して認証情報を受け取るため、ワーカーノードのIAM役割は 多数のAWSリソース。）

a. AWSコンソールで新しく作成されたロールに移動し、[Trust Relationship]タブを選択します
b. 「Edit trust relationship」をクリックします
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/*"
    ]
}
  1. Add the IAM role's name to deployment as an annotation.
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: mydeployment
  namespace: default
spec:
...
  minReadySeconds: 5
  template:
      annotations:
        iam.amazonaws.com/role: my-role
    spec:
      containers:
...

####Kube2iamのデプロイ
Kube2iamポッドで使用するサービスアカウントClusterRoleおよびClusterRoleBindingを作成します。 ClusterRoleには、すべてのAPIグループの名前空間とポッドへの「取得」、「監視」、および「リスト」アクセス権が必要です。 以下のマニフェストを使用して作成できます。

---
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.以下のマニフェストを使用して、Kube2iam DaemonSetをデプロイします。

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）で実行され、privilegedモードでは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つの主要な問題があります。

  • **負荷状態でのデータの競合：**アプリケーションの負荷が非常に高く、クラスターにポッドがいくつかある場合、Kube2iamがそれらのポッドに誤った認証情報を返すことがあります。 GitHubの問題はここで参照できます。
  • プリフェッチ認証情報： コンテナープロセスがポッドで起動する前に、アクセス認証情報がポッド仕様で指定されたIAMロールに割り当てられます。 以前に資格情報を割り当てることにより、Kiamは開始待ち時間を減らし、信頼性を向上させます。

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

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

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

  • **Kiamエージェント：**これは、ポッドが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 master ノードにアタッチされた役割の間の信頼関係を有効にします。 （Kubernetes APIワーカーにアタッチされている役割の権限が非常に制限されていることを確認してください。すべてのAPI呼び出しまたはアクセスリクエストは、ノードで実行されているコンテナによって行われ、Kiamを使用して認証情報を受け取ります。ワーカーノードのIAM役割は多くのAWSリソース。）

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

{
  "Sid": "",
  "Effect": "Allow",
  "Principal": {
    "AWS": "<ARN_KUBERNETES_MASTER_IAM_ROLE>"
  },
  "Action": "sts:AssumeRole"
}
  1. kiam-serverロールにインラインポリシーを追加します。
{
  "Version": "2012-10-17",
  "Statement": [
   {
     "Effect": "Allow",
     "Action": [
       "sts:AssumeRole"
       ],
       "Resource": "*"
   }
 ]
}
  1. AWSリソースへの適切なアクセス権を持つIAMロール（my-roleとしましょう）を作成します。

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

そうするために：

a. AWSコンソールで新しく作成されたロールに移動し、[Trust Relationship]を選択します
b. 「Edit Trust Relationship」をクリックします
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暗号化されています。 これによりセキュリティが強化されます。 これを行うには、まずKubernetesクラスターにcert-managerをデプロイし、エージェント/サーバー通信用の証明書を生成する必要があります。

####Cert Managerの導入と証明書の生成

  • カスタムリソース定義リソースを個別にインストールします。
kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.8/deploy/manifests/00-crds.yaml
  • cert-managerの名前空間を作成します。
kubectl create namespace cert-manager
  • cert-manager名前空間にラベルを付けて、リソース検証を無効にします。
kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true
  • Jetstack Helmリポジトリを追加します。
helm repo add jetstack https://charts.jetstack.io
  • ローカルのHelmチャートリポジトリキャッシュを更新します。
helm repo update
  • cert-manager Helmチャートをインストールします。
helm install --name cert-manager --namespace cert-manager --version v0.8.0 jetstack / cert-manager
  • cert-manager Helmチャートをインストールします。
helm install --name cert-manager --namespace cert-manager --version v0.8.0 jetstack / cert-manager

####Kiam Agent-server TLSのCA秘密鍵と自己署名証明書を生成する

  • 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
  • CA鍵ペアを秘密としてKubernetesに保存します。
kubectl create secret tls kiam-ca-key-pair \
   --cert = ca.crt \
   --key = ca.key \
   --namespace = cert-manager
  • クラスター発行者を展開し、証明書を発行します。

Kiamネームスペースを作成します。

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

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

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
---
  • 証明書が正しく発行されているかどうかをテストします。
kubectl -n kiam get secret kiam-agent-tls -o yaml
kubectl -n kiam get secret kiam-server-tls -o yaml

####リソースに注釈を付ける

  • 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でこれを行う必要はありません。
apiVersion: v1
 kind: Namespace
 metadata:
 	name: default
 	annotations:
 		iam.amazonaws.com/permitted: ".*"

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

  • Kiamエージェントとサーバーのデプロイ
  • Kiamサーバー
  • 以下のマニフェストは、次のものをデプロイします。
  1. Kubernetesマスターノードで実行されるKiam Server DaemonSet（上記で作成されたTLSシークレットを使用するように構成します）
  2. Kiam Serverサービス
  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-server 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. SSL証明書へのパスが、cert-manager証明書を使用して作成したシークレットに従って正しく設定されていることを確認してください。 これは、KiamサーバーとKiamエージェントポッド間の安全な通信を確立するために重要です。

####Kiam エージェント

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

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）。役割はサービスアカウントで認証されるため、そのサービスアカウントが関連付けられているすべてのポッドで共有できます。このサービスは、AWS EKSとKOPSベースのインストールの両方で利用できます。詳しくはこちらをご覧ください。

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

Kube2IAMが最も簡単に実装できますが、セットアップの容易さにより効率が低下します。Kube2iamは高負荷条件下では信頼性の高いパフォーマンスを発揮できない可能性があります。これは、大規模なトラフィックの急増を経験しない非本番環境またはシナリオにより適しています。

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

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

Prometheusが提供するGrafanaダッシュボードでメトリックを視覚化してみたい場合は、MetricFireの無料トライアルに今すぐ参加してください。また、デモにサインアップして、モニタリングソリューションの効果について直接お問い合わせください。（日本語受け付けております）

この記事は、ゲストブロガーのVaibhav Thakurによって書かれたものを翻訳したものです。この記事が気に入った場合は、彼のLinkedInで詳細を確認してください。

1
1
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
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?