EKS Kubernetes プロバイダと下準備

ようやく前回でNodeを起動できるようにしたし、やっとPodを起動してｷｬｯﾊｳﾌﾌできるぜって、そうは問屋が卸さねぇ！

Terraform が Kubernetes を管理できるようにして、さらにちょっとした塩コショウで味付けて、今回は終了です。焦らせば焦らすほどPodの味に深みが増すとか増さないとか。

Kubernetes Provider

まずは作成した EKS Cluster の情報をチュウチュウします。

data "aws_eks_cluster_auth" "main" {
  count = local.on_eks ? 1 : 0

  name = local.eks_cluster_name

  depends_on = [aws_eks_cluster.main]
}

data "aws_eks_cluster_auth" "main" {

count = local.on_eks ? 1 : 0

name = local.eks_cluster_name

depends_on = [aws_eks_cluster.main]

}

そして、そのデータを使ってKubernetesへの接続とします。

provider "kubernetes" {
  host                   = aws_eks_cluster.main[0].endpoint
  token                  = data.aws_eks_cluster_auth.main[0].token
  cluster_ca_certificate = base64decode(aws_eks_cluster.main[0].certificate_authority.0.data)
  load_config_file       = false
}

provider "kubernetes" {

host = aws_eks_cluster.main[0].endpoint

token = data.aws_eks_cluster_auth.main[0].token

cluster_ca_certificate = base64decode(aws_eks_cluster.main[0].certificate_authority.0.data)

load_config_file = false

}

見ての通り、エンドポイントに対して、秘密情報をもって接続している感じです。
これをもって、Terraform の kubernetes_*** のリソースの利用が可能になります。

Config Map

初見ユーザー殺しの項目がきました。下記ページはちゃんと読んで理解すべき内容なのですが、正直いきなり言葉ではなく心で理解できるものではないので、まずは最低限の内容を登録して全体が動くことを確認してから、あとで戻ってきて読むくらいがよいと思います。

クラスターのユーザーまたは IAM ロールの管理 – Amazon EKS

ConfigMap自体は、その名の通り設定情報を扱うものですが、下記設定を登録する理由は上記ページに書いてあり、

ワーカーノードをクラスターに追加するために当初作成されたものですが、

RBAC を IAM ユーザーとロールに追加するために使用することもできます

ということです。そーいえば、前の記事の最後で、Node起動したら追加されて見れるぜって書いたけど、まだあの時点ではダメってことになりますね（笑）

aws-auth 追加

で、公式で配布されている ConfigMap のYAML はここにあって、そのコピペですが

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: <ARN of instance role (not instance profile)>
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

apiVersion: v1

kind: ConfigMap

metadata:

name: aws-auth

namespace: kube-system

data:

mapRoles: |

- rolearn: <ARN of instance role (not instance profile)>

username: system:node:{{EC2PrivateDNSName}}

groups:

- system:bootstrappers

- system:nodes

これを、Terraformで表現するとこうなりますよ、と。

resource "kubernetes_config_map" "main" {
  count = local.on_eks ? 1 : 0

  metadata {
    name      = "aws-auth"
    namespace = local.eks_namespace
  }

  data = {
    mapRoles = <<YAML
- rolearn: ${data.terraform_remote_state.common.outputs.aws_iam_role_eks_node_arn}
  username: system:node:{{EC2PrivateDNSName}}
  groups:
    - system:bootstrappers
    - system:nodes
YAML
  }

  depends_on = [aws_eks_cluster.main]
}

resource "kubernetes_config_map" "main" {

count = local.on_eks ? 1 : 0

metadata {

name = "aws-auth"

namespace = local.eks_namespace

}

data = {

mapRoles = <<YAML

- rolearn: ${data.terraform_remote_state.common.outputs.aws_iam_role_eks_node_arn}

username: system:node:{{EC2PrivateDNSName}}

groups:

- system:bootstrappers

- system:nodes

YAML

}

depends_on = [aws_eks_cluster.main]

}

見ての通りちょっと特徴的な書き方で、metadata と data はそれぞれ項目に分かれてるけど、data の値は YAML でそのまま突っ込むという感じです。Role ARN には、Node用に作成したRoleを割り当てています。

（私は丁寧に確認しませんでしたが）ここまできてようやく、kubectl get nodes –watch などで見ているとノードのステータスが Ready になるらしいので、そういう手順で確認してみてもいいですし、ConfigMap追加後にノード起動するのが普通な気がしますけどね！好きな方でいきましょう。

IAM User の利用許可

Kubernetes を操作できるのは、EKSクラスタを作成したIAM のみが最初は許される状態になっている、と前に書きました。例えば、Terraform用の IAM User terraform で作った場合、terraform ユーザーの鍵を使って kubectl 等を使うということになりますが、他の User / Role も使うことになるのが自然な流れです。

さきほどはEKSに指定された mapRoles のみ追加しましたが、任意の IAM User でも Kubernetes を操作したい場合は、こんな感じで mapUsers を追記してあげると利用できるようになります。普通に User の ARN と、そこから切り出したNameを記述しています。権限うんぬんの細かいところは、それぞれお好みで設計していく感じでよしなに行きましょう。

...
  data = {
    mapRoles = <<YAML
- rolearn: ${data.terraform_remote_state.common.outputs.aws_iam_role_eks_node_arn}
  username: system:node:{{EC2PrivateDNSName}}
  groups:
    - system:bootstrappers
    - system:nodes
YAML
    mapUsers = <<YAML
- userarn: ${data.terraform_remote_state.common.outputs.aws_iam_user_developer_arn}
  username: ${element(split("/", data.terraform_remote_state.common.outputs.aws_iam_user_developer_arn), 1)}
  groups:
    - system:masters
YAML
  }
...

...

data = {

mapRoles = <<YAML

- rolearn: ${data.terraform_remote_state.common.outputs.aws_iam_role_eks_node_arn}

username: system:node:{{EC2PrivateDNSName}}

groups:

- system:bootstrappers

- system:nodes

YAML

mapUsers = <<YAML

- userarn: ${data.terraform_remote_state.common.outputs.aws_iam_user_developer_arn}

username: ${element(split("/", data.terraform_remote_state.common.outputs.aws_iam_user_developer_arn), 1)}

groups:

- system:masters

YAML

}

...

Cluster Role Binding

いわゆるひとつのオマジナイです。下記ページに助けられましたが、

7.1. User “system:anonymous” cannot get resource – Kubernetes Configuration & Best Practices

システム構築中に、User \”system:anonymous\” cannot get resource なるエラーが出たので、それを解決するためだけに追加した設定です。わりと必死にやってた時期だったので、どこで出たか覚えていないし、わざわざ消してエラー箇所を探しに行く気力もありません。

不要な権限なので、セキュリティ的に判断して、インストールが一通り終わったら消すか消さないかするとよいでしょう。

resource "kubernetes_cluster_role_binding" "cluster-system-anonymous" {
  count = local.on_eks ? 1 : 0

  metadata {
    name = "cluster-system-anonymous"
  }
  role_ref {
    api_group = "rbac.authorization.k8s.io"
    kind      = "ClusterRole"
    name      = "cluster-admin"
  }
  subject {
    kind = "User"
    name = "system:anonymous"
  }

  depends_on = [aws_eks_cluster.main]
}

resource "kubernetes_cluster_role_binding" "cluster-system-anonymous" {

count = local.on_eks ? 1 : 0

metadata {

name = "cluster-system-anonymous"

}

role_ref {

api_group = "rbac.authorization.k8s.io"

kind = "ClusterRole"

name = "cluster-admin"

}

subject {

kind = "User"

name = "system:anonymous"

}

depends_on = [aws_eks_cluster.main]

}

全然楽しくない回がようやく終わりました。
こういう設定って最終的には大事なんですけど、初見ではダルくてモチベ下がるだけなんで、なんとかしたいものですが、なんともならないですね。ひたすら心を無にして乗り切りましょう。

次回はようやく、ようやく Pod が起動します！