AWSの一時的な認証情報を�提供するOSSの開発

Makoto Nakai @ Kubernetes Novice Tokyo #23

自己紹介

名前: 中井慎 (a.k.a. Makoto “Dave” Nakai)

所属: 慶應義塾大学政策・メディア研究科修士1年

好きなツール: Golang・Kubernetes・Terraform

好きな技術: Linux・ネットワーク・認証認可

前回の k8snovice からの進捗:�某メガベンチャーにSREとして内定済み

​

​

​

​

​

一言で表すと

AWS外のk8sクラスタからAWSのリソースにアクセスする際に�サービスのPodに対して一時的なAWSの認証情報を提供するOSS �locksmith ( = 英語で鍵職人) を開発した！��GitHub: https://github.com/pepabo/locksmith

​

問題提起

永続的なクレデンシャルを用いたAWSへのアクセスが危険すぎる

プライベートクラウド

AWS

DB

S3

Service

発生しうる問題�1. クレデンシャルのローテーションに影響される範囲の特定が困難�2. クレデンシャルが漏洩した場合AWSに不正アクセスし放題

・Access Key ID

・Secret Access Key

IAM Roles Anywhereが解決の鍵

AWS外のワークロードにIAMロールを付与するサービスIAM Roles Anywhere

プライベートクラウド

AWS

DB

S3

Service

IAM

・一時的なAccess Key ID

・一時的なSecret Access Key

��

IAM Roles Anywhereの導入効果

AWS外のワークロードでIAMロールをAssume → 一時的な認証情報でAWSにアクセス可能！

AWS IAM Anywhereの仕組み

IAM

Service

AWS外

AWS

認証局

CA

ルート/中間CA証明書で

トラストアンカーを作成

ルート/中間�CA証明書

AWS IAM Anywhereの仕組み

IAM

Service

AWS外

AWS

認証局

CA

特殊なAWSロール

AWSプロファイル

を作成

サーバー証明書

サーバー秘密鍵

を作成

IAM Role Anywhereの使用に必要なIAMロール

{{

"Version": "2012-10-17",� "Statement": [� {� "Effect": "Allow",� "Principal": {� "Service": "rolesanywhere.amazonaws.com"� },� "Action": [� "sts:AssumeRole",� sts:SetSourceIdentity",� "sts:TagSession"� ]� }� ]�}

}

​

IAM Roles Anywhereの仕組み

IAM

Service

AWS外

AWS

認証局

CA

トランスアンカー�AWSロール�AWSプロファイル

のARN

サーバー証明書

サーバー秘密鍵

IAM Roles Anywhereの設定ファイルについて

aws_signing_helperというAWSの公式ツールを使えば�IAM Roles Anywhere由来の一時的な認証情報が取得できる

~/.aws/configの例��[default]

credential_process = ./aws_signing_helper credential-process \\� --certificate (サーバー証明書までのパス) \\� --private-key (サーバー秘密鍵までのパス) \\� --trust-anchor-arn (トラストアンカーのARN) \\� --profile-arn (プロファイルのARN) \\� --role-arn (Assume対象のIAMロールのARN)

Kubernetesへの実装方法

Service

� サーバー証明書

サーバー秘密鍵

​

~/.aws/config

aws_signing_helperの実行ファイル

Secret

emptyDir

locksmith�(initContainer)

locksmithとServiceの間で以下を共有��~/.aws/configの中身�aws_signing_helperの実行ファイル�

↓

​

ServiceのPodでも~/.aws/config からAWSの認証情報を取得可能に！

� AWS_TRUST_ANCHOR_ARN

AWS_PROFILE_ARN

AWS_ROLE_ARN

​

↓�

最初に挙げた2つの問題点が解決！(後述)

成果1: クレデンシャルのローテーションが不要に

AWSへの認証時に毎回新しい認証情報を発行する方式に変更�(= とりあえず~/.aws/configから認証情報を取得できればOK)

一時的な認証情報

成果2: ソースコードからのクレデンシャル漏洩を防止できた

~/.aws/configから認証情報を取得するコード例 (Golang)

package main

import (� "context"� "fmt"� "github.com/aws/aws-sdk-go-v2/config"�)

​

func main() {

cfg, err := config.LoadDefaultConfig(context.TODO())� if err != nil {� panic(fmt.Sprintf("failed loading config, %v", err))� }�}

​

aws_signing_helperを実行して初めて認証情報を取得 → コードからの流出なし！

成果3: クレデンシャル不正利用の被害を抑制できた

AWSへの認証時に毎回新しい認証情報を発行する方式に変更�(= 認証情報を傍受されたとしても、デフォルト1時間で失効)

一時的な認証情報

locksmith導入の際の注意点

• 認証情報を~/.aws/configから取得できるようにコードベースを書き換える�
• サービス側のDockerfileにCA certificatesをインストールする
• 発表者はインストールを忘れるとサービス側のaws_signing_helperの認証に失敗した

まとめ

• 永続的なクレデンシャルを用いてAWSリソースにアクセスすると、�ローテーションによる事故や漏洩による不正利用の危険性がある�
• locksmithを用いた認証であればローテーション不要・コードベースからの流出なし・不正利用の被害抑制が全て達成できる�
• locksmithはinitContainerとして起動するので、k8sのマニフェストファイルにも比較的容易に導入できる

謝辞

本OSSはGMOペパボ株式会社のインターンの成果物の一環として実装されたものです。��コーポーレートサイト: https://pepabo.com�

メンターのtakutakaさんはじめ、CTOのあんちぽさん、技術責任者のくんさん、�人事部の皆様、技術部の皆様にこの場を借りて改めて御礼申し上げます。��Takutakaさん: https://twitter.com/takutaka1220�くんさん: https://twitter.com/kenchan�あんちぽさん: https://twitter.com/kentaro�

出典

Obtaining temporary security credentials from AWS Identity and Access Management Roles Anywhere�https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html (参照日時 3月14日)��Creating a trust anchor and profile in AWS Identity and Access Management Roles Anywhere�https://docs.aws.amazon.com/rolesanywhere/latest/userguide/getting-started.html (参照日時 3月14日)

Go 言語で AWS SDK を使う開発環境を整える - まくろぐ�https://maku.blog/p/xnogqgm/ (参照日時 3月14日)�

�

​