はじめに
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/*"
]
}
- 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"
}
- kiam-serverロールにインラインポリシーを追加します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "*"
}
]
}
- 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サーバー
- 以下のマニフェストは、次のものをデプロイします。
- Kubernetesマスターノードで実行されるKiam Server DaemonSet（上記で作成されたTLSシークレットを使用するように構成します）
- Kiam Serverサービス
- 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
....
- kiam-serverロールARNは、Kiamサーバーコンテナーへの引数として提供されます。 上記のマニフェストのフィールドを、作成したロールのARNに更新してください。
- Kiamサーバー用に作成されたClusterRoleおよびClusterRoleBindingは、効果的に動作するために必要な最小限の権限をそれに付与します。 変更する前に十分に検討してください。
- 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で詳細を確認してください。