とことんDevOps | 日本仮想化技術のDevOps技術情報メディア

DevOpsに関連する技術情報を幅広く提供していきます。

日本仮想化技術がお届けする「とことんDevOps」では、DevOpsに関する技術情報や、日々のDevOps業務の中での検証結果、TipsなどDevOpsのお役立ち情報をお届けします。
主なテーマ: DevOps、CI/CD、コンテナ開発、IaCなど

開催予定の勉強会

読者登録と各種SNSのフォローもよろしくお願いいたします。

eksctlとHelmでハマった

eksctlを使うとEKSにサービスアカウントを用意してくれます。これの何が嬉しいかというと、KubernetesのServiceAccountとIAMロールが紐づいてくれるので、kube2iamかkiamを使わなくてもKubernetesからAWSのリソースの操作ができるようになります、やったね☆

詳細は以下から

IAM Roles for Service Accounts - eksctl

で、今回ExternalDNSとAWS Load Balancer Controller用のServiceAccountを追加して、LBの追加やDNSレコードの追加を自動でやらせようと思ったのですが、なぜかPermission deniedになってしまいます、おかしい……

結論

HelmのインストールオプションでserviceAccount.create=trueになっていて、eksctlで作ったSerivceAccountを上書きして、IAMロールとの紐付けが削除されていました。

インストールオプションで--set serviceAccount.create=falseするか、values.yamlでfalseにする必要があるんですね。以前作ったeksctlのコードではfalseにしていたので、過去の自分は知っていたようですが今日の私は知りませんでした。

調査方法

kubectl get serviceaccounts -n NAMESPACE SA_NAME -o yamlで以下のような項目があるか確認すると1発でわかります。

metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::XXXXXXXXXXXX:role/eksctl-demo-addon-iamserviceaccount-kube-sys-RoleN-xxxxxxxxxxxx

eks.amazonaws.com/role-arnにIAMロールのArnがセットされているはずで、このIAMロールをみればどういう権限が付与されているかわかります。 この部分がないと、NodeInstanceRoleに従うはずなので、そっちに権限がなければ操作できない、と……

まとめ

HelmのserviceAccount.createが上書きするとは思っていなくてだいぶ時間を使ってしまいました。