aws-auth ConfigMapをEKSクラスタにCodeシリーズで自動デプロイする仕組みを構築してみた

かたいなか

2019.01.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、かたいなかです。

EKSをチームで運用する際に、EKSクラスタにアクセスする必要があるIAMユーザ/ロールが増えるたび、すでにアクセスできる状態になっている人に依頼してaws-authConfigMapをeditしてもらうというのは大変ですよね。

そこで今回は以下の図のように、Codeシリーズを使用してaws-authConfigMapのYAMLの変更が、Kubernetesのクラスタに自動で反映されるようにする方法をご紹介します。

全体図

おさらい：`aws-auth`ConfigMapとは

aws-authConfigMapはIAMのユーザ/ロールをKubernetes内のユーザやロールに紐付けを定義します。EKSクラスタ作成者以外のIAMのユーザ/ロールは、このConfigMapに紐づけが定義されていないと、Kubernetesクラスタ内のリソースにアクセスすることができません。

具体的には以下のようなConfigMapとなります。

apiVersion: v1
kind: ConfigMap
data:
  mapRoles: |
    - rolearn: arn:aws:iam::XXXXXXXXXXXX:role/devel-worker-nodes-NodeInstanceRole-74RF4UBDUKL6
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
  mapUsers: |
    - userarn: arn:aws:iam::XXXXXXXXXXXX:user/admin
      username: admin
      groups:
        - system:masters
    - userarn: arn:aws:iam::XXXXXXXXXXXX:user/ops-user
      username: ops-user
      groups:
        - system:masters

実際に構築してみる

流れ

以下の流れで進めます。

CodeBuild用サービスロールの準備
1. ロールの作成
2. Kubernetesクラスタ内のaws-authに手動で設定
CodeBuildのビルド環境用 Dockerイメージの準備
1. ECRのリポジトリを作成
2. イメージのビルド・プッシュ
CodeCommitのリポジトリの準備
1. aws-authConfigMapのYAML作成
2. buildspec.yml作成
CodePipeline/CodeBuild作成

前提条件

以下の前提条件を満たした状態であることを前提に進めていきます。

EKSのクラスタが作成されていること
docker,kubectl,aws-iam-authenticator等のツールが作業を行うPCにインストールされていること
kubectlでEKSのクラスタにアクセスできるようになっていること

CodeBuild用サービスロールの準備

まずは、CodeBuildのサービスロールを定義します。

CodeBuildのサービスロールには、以下のようなポリシードキュメントをもつIAM Policyを作成し、アタッチします。

{
  "Version": "2012-10-17",
  "Statement": [
    {
        "Sid": "EKSPolicy",
        "Effect": "Allow",
        "Action": "eks:DescribeCluster",
        "Resource": "*"
    },
    {
      "Sid": "CloudWatchLogsPolicy",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": [
        "*"
      ]
    },
    {
      "Sid": "CodeCommitPolicy",
      "Effect": "Allow",
      "Action": [
        "codecommit:GitPull"
      ],
      "Resource": [
        "*"
      ]
    },
    {
      "Sid": "S3GetObjectPolicy",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion"
      ],
      "Resource": [
        "*"
      ]
    },
    {
      "Sid": "S3PutObjectPolicy",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

EKSのクラスタをdescribeする権限とCodeBuildのサービスロールとして一般的に必要な権限を与えています。

信頼ポリシー

また、CodeBuildがAssume Roleできるようにするため、CodeBuildのサービスロールは以下のような信頼ポリシーを持つようにします。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "codebuild.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

EKSクラスタ内の`aws-auth`ConfigMapにCodeBuildのサービスロールを追加

CodeBuildのサービスロールをaws-authConfigMapに予め手動で追加しておきます。先に追加を済ませておかないとCodeBuildがConfigMapの編集を行えないためです。

以下のようなYAMLを作成します。EKSのクラスタにワーカーノードが追加された時点でワーカーノードのインスタンスのロールに関する設定はされているはずなので、新たにハイライトされた部分のCodeBuildのサービスロールの設定を追加します。

aws-auth.yml

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - username: system:node:{{EC2PrivateDNSName}}
      rolearn: <EKSのワーカーノードのインスタンスのロールのARN>
      groups:
      - system:bootstrappers
      - system:nodes
    - username: codebuild
      rolearn: <CodeBuildのサービスロールのARN>
      groups:
        - system:masters

そして、クラスタに対してこのYAMLをkubectl applyします。

$ kubectl apply -f aws-auth.yml

CodeBuildのビルド環境用 Dockerイメージの準備

ECRのリポジトリを作成

ECRのリポジトリを作成します。

CodeBuildがイメージをpullできるようにするため、以下のようなリポジトリポリシーを付与しておきます。

リポジトリポリシー

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CodeBuildAccess",
      "Effect": "Allow",
      "Principal": {
        "Service": "codebuild.amazonaws.com"
      },
      "Action": [
        "ecr:BatchCheckLayerAvailability",
        "ecr:BatchGetImage",
        "ecr:GetDownloadUrlForLayer"
      ]
    }
  ]
}

Dockerイメージをビルド・ECRにプッシュ

まず、以下のようなDockerfileを用意します。

FROM alpine:3.8

# install AWS CLI
ENV AWS_CLI_VERSION 1.16.26
RUN apk --update --no-cache add \
        python \
        py-pip \
        && \ 
    pip install --upgrade awscli==${AWS_CLI_VERSION} && \
    apk -v --purge del py-pip

# install kubectl
ENV KUBECTL_VERSION 1.11.3
RUN wget -O /usr/local/bin/kubectl https://storage.googleapis.com/kubernetes-release/release/v${KUBECTL_VERSION}/bin/linux/amd64/kubectl && \
    chmod +x /usr/local/bin/kubectl

# install AWS IAM Authenticator
ENV AWS_IAM_AUTHENTICATOR_RELEASE_DATE 2018-07-26
ENV AWS_IAM_AUTHENTICATOR_VERSION 1.10.3
RUN wget -O /usr/local/bin/aws-iam-authenticator https://amazon-eks.s3-us-west-2.amazonaws.com/${AWS_IAM_AUTHENTICATOR_VERSION}/${AWS_IAM_AUTHENTICATOR_RELEASE_DATE}/bin/linux/amd64/aws-iam-authenticator && \
    chmod +x /usr/local/bin/aws-iam-authenticator

そして、以下のようなコマンドでDockerイメージをビルドし、ECRにプッシュします。

$ $(aws ecr get-login --no-include-email --region ap-northeast-1)
$ docker build -t <ECRのリポジトリのURI>:latest .
$ docker push <ECRのリポジトリのURI>:latest

YAMLを管理するCodeCommitリポジトリの準備

CodeCommitのリポジトリを作成し、以下に示すような2つのファイルがプッシュされた状態にします。

まずは先程、EKSのクラスタにapplyしたaws-authConfigMapのYAMLです。

aws-auth.yml

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - username: system:node:{{EC2PrivateDNSName}}
      rolearn: <EKSのインスタンスのロールのARN>
      groups:
      - system:bootstrappers
      - system:nodes
    - username: codebuild
      rolearn: <CodeBuildのサービスロールのARN>
      groups:
        - system:masters

そして、CodeBuildでYAMLの適用をおこなうためのbuildspec.ymlです

buildspec.yml

version: 0.2

phases:
  pre_build:
    commands:
      - aws eks update-kubeconfig --name ${EKS_CLUSTER_NAME}
  build:
    commands:
      - kubectl apply -f aws-auth.yml

CodePipeline/CodeBuildの設定

最後に、CodePipelineのパイプラインをは今まで作ったものをつなげて作成していきます。

CodePipelineのソースに作成したCodeCommitリポジトリのmasterブランチを選択します。
CodeBuildのプロジェクトを以下のような設定で作成し、CodePipelineに関連付けます。
- サービスロールとして予め準備しておいたCodeBuildのロールを使用するようにします。
- CodeBuildの環境として、ECRに予めプッシュしておいたイメージを使用するようにします。
- ビルド定義ファイルはCodeCommitのリポジトリのbuildspec.ymlを指定します。

パイプライン作成が完了したら、処理が自動で開始されます。

正常に処理が完了すれば、構築が正しく行えています。

ここまででCodeCommit上でのaws-auth.yamlの変更が自動でEKSのクラスタに反映されるようになりました。

自動で適用されることを確認してみる

では、実際に反映が正しく行われるか確認してみましょう。

aws-auth.ymlに以下のハイライトの部分を追加してコミットし、CodeCommitにプッシュします。

aws-auth.yml

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - username: system:node:{{EC2PrivateDNSName}}
      rolearn: <EKSのインスタンスのロールのARN>
      groups:
      - system:bootstrappers
      - system:nodes
    - username: codebuild
      rolearn: <CodeBuildのサービスロールのARN>
      groups:
        - system:masters
  mapUsers: |
    - userarn: <追加するIAMユーザのARN>
      username: admin
      groups:
        - system:masters

そして、CodePipelineの処理が成功したのを確認したら、aws-auth.ymlに追加したIAMユーザを使用してkubectlでアクセスできることを確認してましょう。

$ kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.100.0.1   <none>        443/TCP   16h

正しくアクセスが行えました。

まとめ

今回は、EKSのクラスタに対してaws-auth ConfigMapが自動で適用されるようにする方法の例をご紹介しました。今回はCodeシリーズを使用していますが、GitHub等の他のGitホスティングサービスやCircle CI等他のCIツールを使用しても同様の処理を行うことももちろん可能です。

ソースコードリポジトリで管理されたYAMLの変更から aws-auth ConfigMapの適用を自動で行うしくみが作れると、すでにアクセス権を持っている人に依頼してConfigMapをeditしてもらうようなトイルになりがちな作業を削除できます。

実は今回使用した方法は、Kuberenetesの特定のリソースに限った方法ではなく、CodeBuildで実行されるコマンドさえ修正すれば他のKubernetesのリソースの自動デプロイにも応用できるものです。そのため、EKSクラスタを立てたらまずはこのような仕組みを作っておくことで、自動デプロイの仕組みを整えていくのに良いスタートになるのではないかなと思います。

EKSのクラスタを立てた際には試していただけますと幸いです。

参考資料

クラスターのユーザーまたは IAM ロールの管理：EKSのドキュメントのIAMユーザ/ロールとEKSのユーザの関連付けのページです。
actions/example-aws：GitHub ActionsでEKSへのCDの実装例のリポジトリです。
CRD implementation：現在はaws-auth ConfigMapで内のmapRoles, mapUsersというプロパティの属性としてYAMLの文字列を埋め込む形で設定していますが、将来的には、IAMロールとKubernetesのRBACのロールのヒモ付をCustomResourceDefinitionとして設定できるようにすることが検討されているようです。

aws-auth ConfigMapをEKSクラスタにCodeシリーズで自動デプロイする仕組みを構築してみた

おさらい：`aws-auth`ConfigMapとは

実際に構築してみる

流れ

前提条件

CodeBuild用サービスロールの準備

信頼ポリシー

EKSクラスタ内の`aws-auth`ConfigMapにCodeBuildのサービスロールを追加

CodeBuildのビルド環境用 Dockerイメージの準備

ECRのリポジトリを作成

リポジトリポリシー

Dockerイメージをビルド・ECRにプッシュ

YAMLを管理するCodeCommitリポジトリの準備

CodePipeline/CodeBuildの設定

自動で適用されることを確認してみる

まとめ

参考資料

イベント

EVENT【4/23リモート】クラスメソッドのフリーランスエンジニア会社説明会〜AWS / システムアーキテクト案件特集〜を開催します

EVENT【5/28（火）】AWSを最大活用するための1dayカンファレンス

EVENT【5/17（金）】認証機能の開発工数削減をデモで体験！次世代認証基盤サービス『Auth0 by Okta』導入実践ウェビナー

EVENT【5/14（火）】アノテーションの中途向けオンライン会社説明会を開催します

EVENT【5/23（木）】ユースケースに学ぶAWS運用のノウハウ～可視化から統制まで～

EVENT【5/16（木）】Snowflakeを触ってみよう！初めての方向けハンズオンセミナー

EVENT【5/10（金）名古屋】クラスメソッドグループの会社説明会を開催します！

EVENT【4/25（木）リモート】Google Cloudに携わるエンジニアのキャリア～クラスメソッド会社説明会～

EVENT【4/30（火）リモート】クラスメソッドの会社説明会を開催します

EVENT【5/9（木）】組織的なクラウド統制はじめの一歩

aws-auth ConfigMapをEKSクラスタにCodeシリーズで自動デプロイする仕組みを構築してみた

おさらい：aws-authConfigMapとは

実際に構築してみる

流れ

前提条件

CodeBuild用サービスロールの準備

信頼ポリシー

EKSクラスタ内のaws-authConfigMapにCodeBuildのサービスロールを追加

CodeBuildのビルド環境用 Dockerイメージの準備

ECRのリポジトリを作成

リポジトリポリシー

Dockerイメージをビルド・ECRにプッシュ

YAMLを管理するCodeCommitリポジトリの準備

CodePipeline/CodeBuildの設定

自動で適用されることを確認してみる

まとめ

参考資料

イベント

EVENT【4/23リモート】クラスメソッドのフリーランスエンジニア会社説明会 〜AWS / システムアーキテクト案件特集〜 を開催します

EVENT【5/28（火）】AWSを最大活用するための1dayカンファレンス

EVENT【5/17（金）】認証機能の開発工数削減をデモで体験！次世代認証基盤サービス『Auth0 by Okta』導入実践ウェビナー

EVENT【5/14（火）】アノテーションの中途向けオンライン会社説明会を開催します

EVENT【5/23（木）】ユースケースに学ぶAWS運用のノウハウ～可視化から統制まで～

EVENT【5/16（木）】Snowflakeを触ってみよう！初めての方向けハンズオンセミナー

EVENT【5/10（金） 名古屋】クラスメソッドグループの会社説明会を開催します！

EVENT【4/25（木）リモート】Google Cloudに携わるエンジニアのキャリア～クラスメソッド会社説明会～

EVENT【4/30（火）リモート】クラスメソッドの会社説明会を開催します

EVENT【5/9（木）】組織的なクラウド統制 はじめの一歩

関連記事

AWS入門ブログリレー2024 〜Amazon EKS編〜

[アップデート]TerraformのProviderが関数を定義できるようになりました

Kubernetes Explained for Beginners!

今あらためてコンテナ界隈を俯瞰する「Docker/Kubernetes コンテナ開発入門」

おさらい：`aws-auth`ConfigMapとは

EKSクラスタ内の`aws-auth`ConfigMapにCodeBuildのサービスロールを追加

EVENT【4/23リモート】クラスメソッドのフリーランスエンジニア会社説明会〜AWS / システムアーキテクト案件特集〜を開催します

EVENT【5/10（金）名古屋】クラスメソッドグループの会社説明会を開催します！

EVENT【5/9（木）】組織的なクラウド統制はじめの一歩

AWS入門ブログリレー2024　〜Amazon EKS編〜