Goで並行処理のコードを書いている時に以下の疑問が思い浮かびました．
sync.WaitGroupを利用する場合，実行中のゴルーチンでwg.Add(1)を実行すると，wg.Wait()は呼び出し後に追加されたゴルーチンも待ってくれるか？errgroup.Grpupを利用する場合，実行中のゴルーチンでeg.Go()を実行すると，eg.Wait()は呼び出し後に追加されたゴルーチンも待ってくれるか？答えはどちらもYesです．
実際のコードで確かめてみました．具体的なコードと結果は下記を参照してください．
Kubernetes workerをEC2インスタンスで実行する場合，何も設定しないとPodはEC2インスタンスのIAMロールを利用します．このままでは，攻撃者が悪意のあるイメージを利用して情報漏洩や破壊を行うリスクがあります．kube2iamを利用すると，Podに適切なIAMロールを割り当てることが可能です．
本稿では，Amazon EKSで以下を利用する方法を説明します．
ここでは例として，S3バケットの読み取りが必要なアプリケーションをPodで実行するケースを考えます．
kube2iamはAssume Roleという仕組みを利用してPodにIAMロールを割り当てます．Assume Roleに必要なリソースは別のモジュール（kube2iam）で定義します．
# kube2iam/main.tf variable "worker_iam_role_name" { description = "Name of the IAM role of the Kubernetes worker" } data "aws_iam_role" "worker" { name = var.worker_iam_role_name } resource "aws_iam_role_policy" "this" { role = data.aws_iam_role.worker.id name_prefix = "kube2iam" policy = <<EOF { "Version": "2012-10-17", "Statement": [ { "Action": [ "sts:AssumeRole" ], "Effect": "Allow", "Resource": "*" } ] } EOF } data "aws_iam_policy_document" "assume_role_policy" { statement { actions = ["sts:AssumeRole"] principals { type = "Service" identifiers = ["ec2.amazonaws.com"] } principals { type = "AWS" identifiers = [data.aws_iam_role.worker.arn] } } } output "assume_role_policy" { description = "JSON string of IAM policy for Assume Role" value = data.aws_iam_policy_document.assume_role_policy.json }
上記のkube2iamモジュールを利用して，Assume Roleを許可するIAMポリシーをworkerインスタンスに割り当てます．terraform-aws-eks module を利用している場合は以下のように定義します．
module "kube2iam" { source = "./kube2iam" worker_iam_role_name = module.eks.worker_iam_role_name }
S3の読み取りアクセスを許可するIAMロールを作成します．ここでは簡単のため，AWSであらかじめ定義されているポリシーを利用します．
resource "aws_iam_role" "s3_readonly" { name = "s3_readonly" assume_role_policy = module.kube2iam.assume_role_policy } resource "aws_iam_role_policy_attachment" "s3_readonly" { role = aws_iam_role.s3_readonly.id policy_arn = "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess" }
実際には，IAMロールに利用目的を表す名前を付けた方がよいでしょう．例えば，GitLab Runnerであれば gitlab_runner_build_app だったり，アプリケーションであれば app_frontend といった感じです．
stable/kube2iamをデプロイします．
releases: # https://github.com/helm/charts/tree/master/stable/kube2iam - name: kube2iam namespace: kube-system chart: stable/kube2iam values: - host: iptables: true # https://github.com/jtblin/kube2iam#iptables interface: eni+ extraArgs: # https://github.com/jtblin/kube2iam#base-arn-auto-discovery auto-discover-base-arn: "" rbac: create: true
kube2iamはiptablesを利用してPodの通信を横取りします．amazon-vpc-cniを利用している場合は，上記のようにインタフェース名に eni+ を指定します．Calicoを利用している場合は cali+ になります．詳しくはkube2iamのiptablesセクションを参照してください．
kube2iamを利用すると，Podに iam.amazonaws.com/role アノテーションを付与するとIAMロールが割り当てられるようになります．以下の例ではPodに s3_readonly というIAMロールを割り当てています．
apiVersion: v1 kind: Pod metadata: annotations: iam.amazonaws.com/role: s3_readonly spec:
ここでは，以下のコマンドを実行して動作確認を行います．
kubectl run s3 -i --rm --image fstab/aws-cli --restart=Never --overrides '{"metadata":{"annotations":{"iam.amazonaws.com/role":"s3_readonly"}}}' -- /home/aws/aws/env/bin/aws s3 ls
S3バケットの一覧が表示されれば成功です．
kube2iamが適切に設定されていない場合，PodはworkerインスタンスのIAMロールを利用してしまうため，以下のエラーがでます．
An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied
アノテーションに指定したIAMロールが存在しない場合，以下のエラーが表示されます．
Unable to locate credentials. You can configure credentials by running "aws configure".
アノテーションを指定しない場合は何も割り当てられません．
最後に，動作確認用に作成した以下のIAMロールを削除しておきましょう．
resource "aws_iam_role" "s3_readonly" { name = "s3_readonly" assume_role_policy = module.kube2iam.assume_role_policy } resource "aws_iam_role_policy_attachment" "s3_readonly" { role = aws_iam_role.s3_readonly.id policy_arn = "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess" }
個人のAWS環境でプライベートサブネット構成を検証したいけどNATゲートウェイに毎月3,500円も払えない*1ので，NATインスタンスのTerraformモジュール int128/nat-instance/aws を作りました．主な特徴はこちらです．
VPCとサブネットを作成するには terraform-aws-modules/vpc/aws モジュールが便利です．VPCとサブネットに加えてNATインスタンスを作成するには下記のように定義します．
module "vpc" { source = "terraform-aws-modules/vpc/aws" name = "main" cidr = "172.18.0.0/16" azs = ["us-west-2a", "us-west-2b", "us-west-2c"] private_subnets = ["172.18.64.0/20", "172.18.80.0/20", "172.18.96.0/20"] public_subnets = ["172.18.128.0/20", "172.18.144.0/20", "172.18.160.0/20"] enable_dns_hostnames = true } module "nat" { source = "int128/nat-instance/aws" name = "main" vpc_id = module.vpc.vpc_id public_subnet = module.vpc.public_subnets[0] private_subnets_cidr_blocks = module.vpc.private_subnets_cidr_blocks private_route_table_ids = module.vpc.private_route_table_ids }
Terraformを実行すると，下図のようなリソースが作成されます．（プライベートサブネットの各EC2インスタンスは除く）
動作確認のため，AWSコンソールでプライベートサブネットにEC2インスタンスを作成しましょう．作成したEC2インスタンスにSSMセッションマネージャでログインして，外部にアクセスできるか確認してみましょう．
Terraformを実行すると，Auto Scaling Groupとそれに必要なリソース群（セキュリティグループ，ENI，EIPなど）が作成されます．また，プライベートサブネットのデフォルトルートがENIに設定されます．これにより，プライベートサブネットから外部への通信はENIを通るようになります．
Auto Scaling GroupがNATインスタンスを起動すると，User Dataにある以下のスクリプトが実行されます．
これにより，プライベートサブネット内のEC2インスタンスはENIとNATインスタンスを経由して通信できるようになります．
もしNATインスタンスが停止した場合は，Auto Scaling Groupによって新しいNATインスタンスが作成されます．既存のENIとEIPをアタッチするため，外部通信のソースIPを固定できます．
User DataでENIのアタッチとデフォルトゲートウェイを変更する部分は試行錯誤が必要でかなり苦労しました．
マネージドサービスとは逆行する使い方になりますが，iptablesでDNATを有効にするとNATインスタンスのポートをプライベートサブネットに転送できます．例えば，以下のようなスクリプトを追加すれば，NATインスタンスの443ポートをプライベートサブネットにあるEC2インスタンスに転送できます．NLBに課金する代わりにどうぞ．
# Look up the target instance tag_name="TARGET_TAG" target_private_ip="$(aws ec2 describe-instances --filters "Name=tag:Name,Values=$tag_name" | jq -r .Reservations[0].Instances[0].PrivateIpAddress)" # Expose the port of the NAT instance. iptables -t nat -A PREROUTING -m tcp -p tcp --dst "${eni_private_ip}" --dport 8080 -j DNAT --to-destination "$target_private_ip:8080"
Terraformモジュールの詳細については下記を参照してください．