RBAC、IMDSの保護、監査ログでAmazon EKSのセキュリティを強化

著者

Kamil Potrec

2021年7月7日

0 分で読めます

Infrastructure as Code（IaC）の設定ミスは、コードの脆弱性と同じくらい危険です。設定の小さな間違いによって、機密データがインターネット上で閲覧可能になったり、プライベートエンドポイントやダッシュボードが匿名ユーザーからアクセス可能になり、侵害の足がかりとして悪用されたりするおそれがあります。最近のセキュリティ調査では、Kubernetesプラットフォームを標的とするマルウェアの増加が報告されており、安全な設定の必要性が浮き彫りになっています。

このブログシリーズでは、Amazon Elastic Kubernetes Service（EKS）のデプロイで使われるデフォルト設定を見ていきます。そして、小さな設定ミスや意図しない副作用が、どのようにクラスターをEKSのセキュリティ上の問題にさらすのかを解説します。

Amazon Elastic Kubernetes Serviceとは？

Amazon Elastic Kubernetes Serviceは、マネージドKubernetesサービスです。AWSはクラスターのコントロールプレーンコンポーネントの管理を担い、ユーザーはワーカーノードとクラスターリソースを管理します。

Amazon EKSは、コントロールプレーンの高可用性とスケーラビリティに加え、Identity and Access Managementとの連携によるロールベースアクセス制御の管理、KubernetesサービスアカウントとIAMロールの関連付け、需要に応じてワーカーのキャパシティを自動スケーリングするマネージドノードグループ、ログの一元管理などを提供します。機能の全一覧はAmazon EKS公式ドキュメントをご覧ください。

追加コスト以外にマネージドサービスを利用するデメリットとして、コントロールプレーンの設定を細かく制御できなくなることや、コントロールプレーンのデータベースに保存されるデータをAWSが所有するアカウントに置く必要があることが挙げられます。

EKSをすばやくデプロイする

Amazon EKSは、ウェブコンソール、専用のAmazon EKSコマンドラインツール、またはCloudFormationやTerraformなどのIaCツールを使って、さまざまな方法でデプロイできます。

ここではTerraformを使い、デフォルト値でクラスターをデプロイします。このデモで使用するTerraform設定ファイルはこちらのリポジトリにあります。Terraformコマンドの実行と状態変更の保存にはTerraform Cloudを使用します。

EKSクラスターはVPC内で実行する必要があります。このモジュールを使って、TerraformでVPCをデプロイできます。

1module "vpc" {
2  source = "terraform-aws-modules/vpc/aws"
3
4  name = local.cluster_name
5  cidr = var.vpc_cidr
6
7  azs             = var.vpc_azs
8  private_subnets = var.private_subnet_cidrs
9  public_subnets  = var.public_subnet_cidrs
10
11  enable_nat_gateway     = var.enable_nat_gateway
12  single_nat_gateway     = var.single_nat_gateway
13  one_nat_gateway_per_az = var.one_nat_gateway_per_az
14}

デモ環境では、プライベートサブネットを3つ、パブリックサブネットを3つデプロイします。プライベートサブネットには、インターネットゲートウェイへのデフォルトルートがありません。NATゲートウェイを使って、プライベートサブネットからインターネットにアクセスできるようにします。注：デモ用にNATゲートウェイは1つだけデプロイします。デモ環境のネットワークアーキテクチャの概要を以下に示します。

インターネットゲートウェイ、3つのアベイラビリティーゾーン、パブリックサブネットとプライベートサブネット、およびパブリックサブネットにルーティングされるトラフィックを示すAWS VPCの図。

EKSクラスターには、既存のVPCのIDと、ノードプールとの通信やサービスおよびIngressコントローラー用のロードバランサーのプロビジョニングに使うサブネットIDが必要です。デモ環境では、3つのインスタンスを持つセルフマネージドノードグループをデプロイします。

1module "cluster" {
source          = "terraform-aws-modules/eks/aws"
cluster_name    = local.cluster_name
cluster_version = var.cluster_version
subnets         = module.vpc.private_subnets
vpc_id          = module.vpc.vpc_id
7
worker_groups = [
  {
    instance_type = var.wg_instance_type
    asg_max_size  = var.wg_asg_max_size
  }
]
14}

Terraform Cloudでは、UIまたはリモートオペレーションを使ってプランを実行できます。UIから操作を開始するには、バージョン管理システムにコードをコミットする必要があります。リモートオペレーションを使うと、ローカルの設定ファイルの状態をすばやく確認できます。内部では、Terraformがローカル設定ファイルのアーカイブをリモートサーバーにアップロードし、コマンドをリモートで実行して、結果をターミナルにストリーミングします。Terraform Cloudで管理される状態ファイルを使うには、正しいワークスペースと組織を指定したbackend設定を追加する必要があります。

1terraform {
backend "remote" {
  hostname = "app.terraform.io"
  # TODO: update with your own organization
  organization = "your-unique-organization-name"
6
  workspaces {
    name = "eks-demo-deployments"
  }
}
11}

また、Terraform CloudへのAPIアクセスも必要です。設定方法については、Terraform Cloud公式ドキュメントをご覧ください。

初回のプランでは、設定ファイルによって44個の新しいリソースが作成されることが示されます。

1dev@pwnbox:adversarialengineering/eks-demo-deployments/terraform/default$ terraform plan
2Running plan in the remote backend. Output will stream here. Pressing Ctrl-C
3will stop streaming the logs, but will not stop the plan running remotely.
4
5Preparing the remote plan...
6
7The remote workspace is configured to work with configuration at
8terraform/default/ relative to the target repository.
9<OMITTED>
10     + tags                             = {
11          + "Name" = "eks-threat-modelling-5FZtd82l"
12        }
13      + tags_all                         = {
14          + "Name" = "eks-threat-modelling-5FZtd82l"
15        }
16    }
17
18Plan: 44 to add, 0 to change, 0 to destroy.

これでTerraform CloudのUIから環境をデプロイできます。完了すると、概要ページで新しいクラスターの出力情報を確認できるようになります。

クラスターエンドポイント、名前、セキュリティグループID、Kubernetes設定の出力を含む、適用済みのEKS構成を示すTerraform Cloudの実行結果。

環境をデプロイしたら、AWS公式ドキュメントを参考にしてデモクラスターにアクセスできます。

1dev@pwnbox:~$ aws eks --region eu-west-1 update-kubeconfig --name eks-threat-modelling-5FZtd82l
2Added new context arn:aws:eks:eu-west-1:123456789012:cluster/eks-threat-modelling-5FZtd82l to /home/dev/.kube/config
3dev@pwnbox:~$ kubectl get svc
4NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
5kubernetes   ClusterIP   172.20.0.1   <none>        443/TCP   15m
6dev@pwnbox:~$

このクラスターを評価のベースラインとします。まず、クラスターへの接続がいかに簡単だったか、最初の観察結果を見ていきましょう。

Kubernetes APIへのアクセスを制限する

EKSサービスでは、サービスエンドポイントを通じてKubernetes APIにアクセスできます。デフォルトでは、クラスターのエンドポイントはパブリックにアクセス可能です。つまり、インターネット上の誰もがアクセスを試みることができます。Kubernetes APIはデフォルトで匿名リクエストを受け付けますが、ABACとRBACの認可機構はどちらも、匿名ユーザーや未認証ユーザーに対する明示的な認可を必要とします。EKSクラスターではデフォルトでRBACが有効になっており、APIサーバーのフラグを確認すれば検証できます。

1FLAG: --authentication-token-webhook-cache-ttl="7m0s"
2FLAG: --authentication-token-webhook-config-file="/etc/kubernetes/authenticator/apiserver-webhook-kubeconfig.yaml"
3FLAG: --authentication-token-webhook-version="v1beta1"
4FLAG: --authorization-mode="[Node,RBAC]"
5FLAG: --authorization-policy-file=""
6FLAG: --authorization-webhook-cache-authorized-ttl="5m0s"
7FLAG: --authorization-webhook-cache-unauthorized-ttl="30s"
8FLAG: --authorization-webhook-config-file=""
9FLAG: --authorization-webhook-version="v1beta1"

ログからは、EKSがWebhookトークン認証方式を実装していることもわかります。つまり、KubernetesユーザーはAWS APIから認証トークンを取得する必要があります。これはクラスターのKubernetes APIエンドポイントとは別のものです。Amazon EKSは、クラスターが行う認可の判断に影響を与えません。

さらに確かめるため、認証情報なしでクラスターへの接続を試すことができます。匿名ユーザーをシミュレートするには、認可ヘッダーを付けずにAPIへリクエストを送信します。kubectlには便利なデバッグオプションがあり、すべてのリクエストをCURLコマンドとして出力するため、そのまま再利用できます。

1dev@pwnbox:$ kubectl get pod -v 9
2<OMITTED>
3I0620 13:50:56.340980      19 round_trippers.go:425] curl -k -v -XGET  -H "Accept: application/json;as=Table;v=v1;g=meta.k8s.io,application/json;as=Table;v=v1beta1;g=meta.k8s.io,application/json" -H "User-Agent: kubectl/v1.20.1 (linux/amd64) kubernetes/c4d7527" 'https://DC83F13246D9B2E468D2CAAD692EAF22.yl4.eu-west-1.eks.amazonaws.com/api/v1/namespaces/default/pods?limit=500'
4I0620 13:50:56.435282      19 round_trippers.go:445] GET https://DC83F13246D9B2E468D2CAAD692EAF22.yl4.eu-west-1.eks.amazonaws.com/api/v1/namespaces/default/pods?limit=500 200 OK in 94 milliseconds
5I0620 13:50:56.435317      19 round_trippers.go:451] Response Headers:
6I0620 13:50:56.435326      19 round_trippers.go:454]     Audit-Id: 4814a650-c35b-4c98-bc0c-ba22fb3d58ce
7I0620 13:50:56.435334      19 round_trippers.go:454]     Cache-Control: no-cache, private
8I0620 13:50:56.435342      19 round_trippers.go:454]     Content-Type: application/json
9I0620 13:50:56.435349      19 round_trippers.go:454]     Content-Length: 2926
10I0620 13:50:56.435356      19 round_trippers.go:454]     Date: Sun, 20 Jun 2021 13:50:56 GMT
11I0620 13:50:56.436467      19 request.go:1107] Response Body: {"kind":"Table","apiVersion":"meta.k8s.io/v1","metadata":{"selfLink":"/api/v1/namespaces/default/pods","resourceVersion":"12794"},"columnDefinitions"

正しい認可ヘッダーを付けずに同じリクエストを送信すると、認可されなかったことがわかります。

1dev@pwnbox:$ curl -k -v -XGET  https://DC83F13246D9B2E468D2CAAD692EAF22.yl4.eu-west-1.eks.amazonaws.com/api/v1/namespaces/default/pods?limit=500'
2<OMITTED>
3{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
7
},
"status": "Failure",
"message": "pods is forbidden: User \"system:anonymous\" cannot list resource \"pods\" in API group \"\" in the namespace \"default\"",
"reason": "Forbidden",
"details": {
  "kind": "pods"
},
"code": 403

デフォルトではリソースへのアクセスがある程度制限されていることを確認できました。ここで、多層防御について触れておきましょう。これは、セキュリティシステムにおける単一障害点をなくすため、さまざまな種類のセキュリティ制御を重ねるという考え方です。現在のデプロイでは、インターネット上の誰かによるクラスターへのアクセスを防ぐ制御はRBAC権限だけです。

この設定ファイルは、匿名アクセスを許可する方法を示しています。

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRoleBinding
3metadata:
4  name: read-only
5subjects:
6- kind: User
7  name: system:anonymous
8roleRef:
9  kind: ClusterRole
10  name: view
11  apiGroup: rbac.authorization.k8s.io

この設定を適用すると、匿名リクエストが成功することを確認できます。

1dev@pwnbox:$ curl -k -v -XGET https://DC83F13246D9B2E468D2CAAD692EAF22.yl4.eu-west-1.eks.amazonaws.com/api/v1/namespaces/default/pods?limit=500'
2<OMITTED>
3{
"kind": "PodList",
"apiVersion": "v1",
"metadata": {
  "selfLink": "/api/v1/namespaces/default/pods",
  "resourceVersion": "15018"
},
"items": []

Kubernetesの開発者は、この種の設定を明示的に行う必要があるよう、いくつかの安全対策を導入しています。system:anonymousユーザーとsystem:unauthenticatedグループは、subjects属性に明示的に指定する必要があります。*などのワイルドカード文字を使っても、この2つのsubjectへのアクセスは許可されません。例のsubjectのnameを*に変更して、確認できます。

Kubernetes APIサーバーへのパブリックアクセスは、認証情報が漏えいした場合の影響も大きくします。APIがパブリックにアクセス可能だと、漏えいした認証情報が世界中のどこからでも悪用される可能性があります。また、認可フローでゼロデイ脆弱性が発見された場合も、APIサーバーにパケットを送信できるユーザーを制限する大きな理由になります。過去には、CVE-2019-11253やCVE-2020-8559などの脆弱性が報告されています。

アクセス可能なIPアドレスを制限すれば、パブリックエンドポイントのリスクを軽減できます。Terraformでは、モジュール定義にcluster_endpoint_public_access_cidrs属性を追加して設定できます。

もう1つの方法は、パブリックエンドポイントを完全に無効化し、プライベートVPCエンドポイントを有効にすることです。Terraformモジュールのcluster_endpoint_private_access属性とcluster_endpoint_public_access属性で設定できます。これにより、VPCネットワークにアクセスできるユーザーだけがクラスターにアクセスできます。

ただし、どちらの方法も運用コストに大きく影響します。Terraform Cloudのようなパブリックな継続的デプロイシステムを使う場合、パブリックエンドポイントがないと問題が生じる可能性があります。デモ環境でパブリックエンドポイントを無効にすると、次のアクセス拒否エラーが発生し、デプロイに失敗しました。

リソースの作成・更新中にEKSクラスターのヘルスチェックリクエストがタイムアウトしたことを示すTerraform Applyのエラー。

このエラーが発生するのは、Terraformモジュールが内部でaws-auth ConfigMapを更新しようとするためです。この更新はKubernetes API経由でしか行えません。ご覧のとおり、APIサーバーのFQDNはプライベートIPアドレスに解決されており、プロバイダーから接続できません。TerraformモジュールでConfigMapの管理を無効にすれば、このエラーを解決できます。ただし、それ以降は別の方法で認可用ConfigMapを管理する必要があります。

パブリックエンドポイントを完全に無効にするには、VPC内で実行してプライベートエンドポイントにアクセスするCDシステムを実装するか、接続をプロキシする必要があります。AWS CodePipelineで実現する方法を解説したこちらの記事は参考になります。また、こちらのTerraformモジュールを使えば、AWS Fargateサービス内でAtlantisを実行できます。

開発者のアクセスも複雑になる可能性があります。プライベートエンドポイントへのアクセスを提供するには、踏み台サーバーまたはVPNサービスを用意する必要があるためです。

インスタンスメタデータサービスへのアクセスを制限する

EKSはインスタンスプロファイルを使って、ノード上で実行されるkubeletにAWS権限を付与します。この認証情報には、インスタンスメタデータサービス（IMDS）を介してkubeletがアクセスできます。IMDSには、リンクローカルIPアドレスへのHTTPリクエストでアクセスできます。デフォルトでは、ノード上のすべてのPodからこのメタデータサービスに到達できます。Podを実行してSTSトークンを取得すれば確認できます。

1apiVersion: v1
2kind: Pod
3metadata:
4  name: aws
5  namespace: default
6spec:
7  containers:
8  - name: aws
9    image: amazon/aws-cli:latest
10    command:
11      - sleep
12      - "3600"
13    imagePullPolicy: IfNotPresent
14  restartPolicy: Always
15
16dev@pwnbox:$ kubectl exec -it aws -- /bin/bash
17bash-4.2# aws sts get-caller-identity
18{
19    "UserId": "AROAYREY3WYOLQYZ5IGZJ:i-0f52c37fc0a7a4a44",
20    "Account": "123456789012",
21    "Arn": "arn:aws:sts::123456789012:assumed-role/eks-threat-modelling-5FZtd82l20210620220209389400000009/i-0f52c37fc0a7a4a44"
22}
23bash-4.2#

上記の方法では、ノードに割り当てられたすべての権限を使えます。これは明らかな権限昇格のセキュリティ問題です。デフォルトでは、PodがAWSへのアクセスを必要とするべきではありません。

この問題を緩和するには、PodからIMDSへのネットワークアクセスを制限するしかありません。IMDSには2つのバージョンがあります。バージョン1はリクエストとレスポンスの方式で、リンクローカルアドレスにパケットを送信できるプロセスなら誰でもクエリできます。バージョン2はセッション方式で、レスポンスメッセージの有効期間（TTL）を任意に設定できます。AWSのドキュメントによると、IMDSv1はIMDSv2と併存する形で引き続き利用できます。

AWS標準の設定でこの問題の影響を抑えるには、IMDSv1を完全に無効化する必要があります。ワーカーノードのmetadata_http_tokens属性をrequiredに設定すれば無効化できます。次に、レスポンスパケットのTTLを1に制限します。これはサービスのデフォルトの動作です。TTLを1にすると、KubernetesのネットワークレイヤーはパケットをPodのネットワーク名前空間に転送できなくなります。

1dev@pwnbox:$ kubectl exec -it aws -- aws sts get-caller-identity
2
3Unable to locate credentials. You can configure credentials by running "aws configure".
4command terminated with exit code 253

Amazon EKS用のTerraformモジュールは、ノードの作成にオートスケーリンググループと起動テンプレートを使用します。そのため、メタデータサービスの設定を更新した場合、インスタンスを更新する必要があります。

この解決策には、hostNetworking属性がtrueに設定されたPodは、引き続き認証情報を取得できるという制限があります。

1apiVersion: v1
2kind: Pod
3metadata:
4  name: aws-node
5  namespace: default
6spec:
7  hostNetwork: true
8  containers:
9  - name: aws-node
10    image: amazon/aws-cli:latest
11    command:
12      - sleep
13      - "3600"
14    imagePullPolicy: IfNotPresent
15  restartPolicy: Always
16
17dev@pwnbox:$ kubectl exec -it aws-node -- aws sts get-caller-identity
18{
19    "UserId": "AROAYREY3WYOLQYZ5IGZJ:i-0e0ecce7af113398b",
20    "Account": "123456789012",
21    "Arn": "arn:aws:sts::123456789012:assumed-role/eks-threat-modelling-5FZtd82l20210620220209389400000009/i-0e0ecce7af113398b"
22}
23

Kubernetes標準のネットワークポリシーを使ってリンクローカルIPアドレスへのアクセスを制限し、IMDSへのアクセスを防ぐこともできます。AWS Calicoのドキュメントに、Calico CNIプラグインのインストール手順が記載されています。以下のネットワークポリシーでIMDSへのアクセスを防止できます。CalicoプラグインはhostNetworkがtrueに設定されたPodを隔離しないため、IMDSv1を無効化して最大TTLを1に設定する標準的な方法と同じ制約があります。ただし、ネットワークポリシーならノードの入れ替えは不要で、Pod内でIMDSが必要な場合も、特定のPodに適用できます。

1apiVersion: crd.projectcalico.org/v1
2kind: GlobalNetworkPolicy
3metadata:
4  name: block-metadata-egress-only
5spec:
6  selector: all()
7  egress:
8  - action: Deny
9    protocol: TCP
10    destination:
11      nets:
12      - 169.254.169.254/32
13  - action: Allow
14    destination:
15      nets:
16      - 0.0.0.0/0
17
18dev@pwnbox:$ kubectl exec -it aws -- aws sts get-caller-identity
19{
20    "UserId": "AROAYREY3WYOLQYZ5IGZJ:i-06a05d6ddfff5b2bd",
21    "Account": "123456789012",
22    "Arn": "arn:aws:sts::123456789012:assumed-role/eks-threat-modelling-5FZtd82l20210620220209389400000009/i-06a05d6ddfff5b2bd"
23}
24dev@pwnbox:$ kubectl apply -f tests/disable-imds-network-access/network-policy.yaml
25globalnetworkpolicy.crd.projectcalico.org/allow-all-egress-except-ec2-metadata created
26dev@pwnbox:$ kubectl exec -it aws -- aws sts get-caller-identity
27
28Unable to locate credentials. You can configure credentials by running "aws configure".
29command terminated with exit code 253
30dev@pwnbox:$

ログを有効にする

EKSクラスターが外部および内部の脅威にさらされる可能性のある設定ミスをいくつか確認しました。次に、こうしたイベントを監査できるか見てみましょう。Kubernetesの監査ログを使うと、管理者はクラスターのユーザーやサービスが実行した操作を監視できます。残念ながら、EKSではデフォルトで有効になっていません。デフォルトのTerraformモジュール設定でも同様です。ログを有効にするには、cluster_enabled_log_types属性を使用し、必要なログタイプを指定します。

EKSでは、複数の種類のログをそれぞれ個別に有効にできます。セキュリティの観点では、主にauditログとauthenticatorログが重要です。

監査ログを使うと、Kubernetesへのリクエストを監視し、それらを実行したエンティティを特定できます。監査ログはクラスターで行われた操作ごとにイベントを生成するため、デフォルトの送信先であるCloudWatchに対して、大量のデータがストリーミングされる点に注意してください。auditとauthenticatorに絞ることで、データ量を抑えられます。

たとえば、aws-configマップへの更新を検索し、改ざんがないか確認できます。次のフィルターを使うと、aws-authという名前のオブジェクトに関連するすべてのパッチイベントを取得できます。

1{ ($.verb = "patch") && ($.objectRef.name = "aws-auth") }

監査イベントには、誰が変更したのか、どこから接続したのかなどを特定するのに役立つ情報が含まれています。

1{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "844b26da-3ce9-4062-b7aa-3c0a869d9e45",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/namespaces/kube-system/configmaps/aws-auth?fieldManager=kubectl-edit",
  "verb": "patch",
  "user": {
      "username": "kubernetes-admin",
      "uid": "heptio-authenticator-aws:123456789012:AROAYREY3WYOBFHU7VIRM",
      "groups": [
          "system:masters",
          "system:authenticated"
      ],
      "extra": {
          "accessKeyId": [
              "ASIAYREY3WYOETXWXAOG"
          ]
      }
  },
  "sourceIPs": [
      "12.34.256.27"
  ],
  "userAgent": "kubectl/v1.20.1 (linux/amd64) kubernetes/c4d7527",
  "objectRef": {
      "resource": "configmaps",
      "namespace": "kube-system",
      "name": "aws-auth",
      "apiVersion": "v1"
  },
  "responseStatus": {
      "metadata": {},
      "code": 200
  },
  <OMITTED>

また、これらのログは権限のないユーザーによるリソースへのアクセス試行の検知にも役立ちます。次のクエリを使うと、匿名ユーザーから送信されたリクエストを検索できます。

1{ ($.user.username = *anonymous) }
2
3{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "Metadata",
  "auditID": "68f24024-080b-4ae7-a97b-fd5fd9792e31",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/namespaces/kube-system/configmaps/aws-auth",
  "verb": "get",
  "user": {
      "username": "system:anonymous",
      "groups": [
          "system:unauthenticated"
      ]
  },
  "sourceIPs": [
      "12.34.256.27"
  ],
  "userAgent": "kubectl/v1.20.1 (linux/amd64) kubernetes/c4d7527",
  "objectRef": {
      "resource": "configmaps",
      "namespace": "kube-system",
      "name": "aws-auth",
      "apiVersion": "v1"
  },
  "responseStatus": {
      "metadata": {},
      "status": "Failure",
      "reason": "Forbidden",
      "code": 403
  },
  "requestReceivedTimestamp": "2021-06-21T17:08:02.384514Z",
  "stageTimestamp": "2021-06-21T17:08:02.384693Z",
  "annotations": {
      "authorization.k8s.io/decision": "forbid",
      "authorization.k8s.io/reason": ""
  }
39}

一方、authenticatorログを使うと、クラスターへのログインを試みているユーザーを追跡し、これらのエンティティをKubernetesのグループやユーザーと関連付けられます。前の例から、キーIDがAROAYREY3WYOBFHU7VIRMのユーザーがConfigMapを変更したことは分かりますが、このキーIDがどのAWSエンティティに属するのかは分かりません。

1ime="2021-06-21T16:32:01Z" level=info msg="access granted" arn="arn:aws:iam::123456789012:role/ci" client="127.0.0.1:39092" groups="[system:masters]" method=POST path=/authenticate sts=sts.eu-west-1.amazonaws.com uid="heptio-authenticator-aws:123456789012:AROAYREY3WYOBFHU7VIRM" username=kubernetes-admin

次回：Amazon EKSの高度なハードニング

今回のブログ記事では、Amazon Elastic Kubernetes Serviceの利用時に発生する可能性のある、認証・認可やインスタンスメタデータサービスへのアクセスなどのセキュリティ上の問題をいくつか取り上げました。また、本番環境でこれらの問題を軽減する方法も紹介しました。このシリーズの次回の記事では、Amazon EKSクラスターを分離するための重要なステップであるマルチアカウントアーキテクチャや、Amazon EKSクラスターの作成時に専用のIAMロールを使用することの重要性、Amazon EKSコントロールプレーンに保存されたシークレットをさらに保護する方法について解説します。次回の記事をお待ちいただくか、公開時のお知らせを受け取るためにTwitterで@snkysecをフォローしてください。

Snyk Infrastructure as Code (Snyk IaC)のスキャンを利用すると、CloudFormationやTerraformを使ったAmazon EKSの利用に伴うセキュリティ上の問題を軽減できます。デプロイコードが本番環境に反映される前に、セキュリティ上の問題を特定できます。無料アカウントに登録して、スキャンを始めましょう。

ソースコードの段階からインフラを保護

Snykはワークフロー内のIaCセキュリティとコンプライアンスを自動化し、構成ドリフトや不足しているリソースを検出します。

ライブデモを予約無料で始める