こんにちは。技術課の山本です。
以前の記事で IAM Roles Anywhere の概要に触れました。
おまけ、OpenSSL 篇:
今回は上の記事で解説した構成を、実際に構築してみます。
認証局は Private CA (Short-Liveモード) を使用して構築します。
※ 図内に書いている「S3 バケットにファイルをアップロードする処理」は、本記事では「S3 バケットのファイルを参照する処理」に変更しました。ご了承ください。
目次:
- IAM Roles Anywhere を構築してみる。
- オンプレミスのサーバーで秘密鍵と署名リクエスト(CSR)を作成
- 認証局(Private CA (Short-Liveモード) )を作成する
- 認証局(Private CA (Short-Liveモード) )からエンドエンティティ証明書を発行する
- エンドエンティティ証明書をダウンロードしてオンプレミスのサーバーに配置する
- オンプレミスのサーバーが、IAM Roles Anywhere のサービスを経由して引き受けるロールの準備
- IAM Roles Anywhere を使用する準備
- オンプレミスのサーバーにヘルパーツール (aws_signing_helper)を導入し、IAM Roles Anywhere を使用する
- まとめ
- 余談
IAM Roles Anywhere を構築してみる。
オンプレミスのサーバーで秘密鍵と署名リクエスト(CSR)を作成
オンプレミスのサーバーで秘密鍵と署名リクエスト(CSR)を作成します。
openssh コマンドを使用します。
openssl req -out csr.pem -new -newkey rsa:2048 -nodes -keyout private-key.pem
作成した秘密鍵と署名リクエスト(CSR)を確認します。
openssl req -in csr.pem -text -noout
署名リクエスト(csr.pem) と秘密鍵(private-key.pem)が出来ました。
署名リクエスト(csr.pem) の中身を、のちの手順で使用するため控えておきます。
認証局(Private CA (Short-Liveモード) )を作成する
認証局(Private CA (Short-Liveモード) )を作成します。
暗号化方式は、RSA でも ECDSA でもよいです。本記事では RSA 2048 としています。
To authenticate a request for credentials, IAM Roles Anywhere validates the incoming signature by using the signature validation algorithm required by the key type of the certificate, for example RSA or ECDSA.
認証局(Private CA (Short-Liveモード) )が出来ました。
認証局(Private CA (Short-Liveモード) )が Pending certificate 状態になっていますので、ルート CA 証明書をインストールします。
デフォルトの有効期限は10年です。
伸ばすことも可能です。
ルート証明書 ルート CA 証明書を変更すると、PKI (パブリックキーインフラストラクチャ) 全体に影響するため、依存するすべてのクライアントオペレーティングシステムとブラウザの信頼ストアを更新する必要があります。運用上の影響を最小限に抑えるには、ルート証明書の有効期間を長くする必要があります。ルート証明書の AWS Private CA デフォルトは 10 年です。
引用元:プライベート CA ライフサイクルの管理 - AWS Private Certificate Authority
伸ばして作成してみます。(2200年3月15日に変更しました。)
認証局(Private CA (Short-Liveモード) )が Active 状態になりました。
ルート CA 証明書の情報は、以下から確認できます。
最後に、のちの手順で使用するため、認証局(Private CA (Short-Liveモード) )の ARN を控えてください。
認証局(Private CA (Short-Liveモード) )からエンドエンティティ証明書を発行する
認証局(Private CA (Short-Liveモード) )からエンドエンティティ証明書を発行します。
エンドエンティティ証明書を発行する API:IssueCertificate は、AWSマネジメントコンソールから実行できないため、CloudShell を使います。
最初の手順で控えた 署名リクエスト(csr.pem) を CloudShell 上に作成します。
エンドエンティティ証明書を発行するコマンドは以下です。
「--certificate-authority-arn」の中身を、先の手順で控えた認証局(Private CA (Short-Liveモード) )の ARN に置き換えてください。
暗号化方式は 認証局 の作成時に選んだ RSA (SHA256WITHRSA)にしています。
有効期間は、Short-Live モードの最長である7日にしました。
aws acm-pca issue-certificate \ --certificate-authority-arn arn:aws:acm-pca:region:account:certificate-authority/CA_ID \ --csr fileb://csr.pem \ --signing-algorithm "SHA256WITHRSA" \ --validity Value=7,Type="DAYS"
上記コマンドを実行すると、作成したエンドエンティティ証明書の ARN (CertificateArn) を出力します。
エンドエンティティ証明書の ARN (CertificateArn) を控えておきます。
エンドエンティティ証明書をダウンロードしてオンプレミスのサーバーに配置する
以下のコマンドでエンドエンティティ証明書を cert.pem ファイルに書き込みます。
「--certificate-authority-arn」は前の手順でも使用した認証局(Private CA (Short-Liveモード) )の ARN です。
「--certificate-arn」は、1つ前のコマンドが出力したエンドエンティティ証明書の ARN (上で控えたもの)です。
aws acm-pca get-certificate \ --certificate-authority-arn arn:aws:acm-pca:region:account:certificate-authority/CA_ID \ --certificate-arn arn:aws:acm-pca:region:account:certificate-authority/CA_ID/certificate/CERTIFICATE_ID | \ jq -r .'Certificate' > cert.pem
エンドエンティティ証明書ファイル(cert.pem)をCloudShell からダウンロードし、オンプレミスのサーバーに配置します。
オンプレミスのサーバーが、IAM Roles Anywhere のサービスを経由して引き受けるロールの準備
オンプレミスのサーバーが、IAM Roles Anywhere のサービスを経由して引き受けるロールを準備します。
信頼ポリシーを以下のように定義します。
画面:
中身:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "rolesanywhere.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity", "sts:TagSession" ], "Condition": { "StringEquals": { "aws:PrincipalTag/x509Issuer/CN": "sample", "aws:PrincipalTag/x509Issuer/OU": "tech", "aws:PrincipalTag/x509Subject/CN": "sample", "aws:PrincipalTag/x509Subject/OU": "tech" } } } ] }
補足: IAM ロールを引き受けることができる条件(Condition 句)を以下にしています。
- 認証に使用するエンドエンティティ証明書の Issuer ・ Subject 内にある CN と OU の値が、Condition句内に定義した値と一致すること
本定義により、「特定の IAM ロールを引き受けることができるのは、ある特定のエンドエンティティ証明書で認証した場合のみ」という制限を実現可能です。 この Condition 句がないと、信頼アンカーに登録している証明書であれば、どの証明書を用いても IAM ロールを引き受けることができるようになります。
エンドエンティティ証明書の Issuer や Subject 以外にも、Subject Alternative Name (SAN) の内容でも制限可能です。
The Subject, Issuer, and Subject Alternative Name (SAN) fields from X509 certificates are extracted and used as PrincipalTag elements in the session.
和訳:
「Subject、Issuer、Subject Alternative Name (SAN) の各フィールドを、 X509 の証明書から抽出します。セッション中に、これらの要素をプリンシパルタグ (PrincipalTag) で使用可能です。」
引用元:Trust model in AWS Identity and Access Management Roles Anywhere - IAM Roles Anywhere
なお、ダウンロードしたエンドエンティティ証明書のSubject、Issuer、Subject Alternative Name (SAN) の各フィールドを確認するには、openssl コマンドを使用します。(cert.pem は証明書ファイル名)
openssl x509 -text -noout -in cert.pem
次に、IAM ロールに付与する許可ポリシーに、 S3 の読み取りアクセスを付与します。
最後に、任意の名前を付与して IAM ロールを作成します。以下の名前としました。
- iam-roles-anywhere-test-yamamoto
IAM Role の ARN を控えておきます。
- arn:aws:iam::123456789012:role/iam-roles-anywhere-test-yamamoto
IAM Roles Anywhere を使用する準備
IAM Roles Anywhere を使用する準備をします。
IAM のサービス画面の以下(IAM ロールの下)に、IAM Roles Anywhere の設定画面があります。
IAM はグローバルサービスですが、IAM Roles Anywhere はリージョンサービスです。
認証局(Private CA (Short-Liveモード) )と同じリージョンに合わせてください。
[Create a trust anchor] を押して、信頼アンカーを作ります。
先に作成した認証局(Private CA (Short-Liveモード) )を指定してください。
できました。
次に [Create a profile] を押して、プロファイルを作ります。
任意の名前をつけます。
IAM ロールには先の手順で作成した、オンプレミスのサーバーが、IAM Roles Anywhere のサービスを経由して引き受けるロールを入れます。
セッションポリシー (Session Policies) は IAM ロールの権限を制限できる機能です。今回はデフォルトのまま(制限なし)とします。
できました。
作成した信頼アンカーと、プロファイルの ARN を控えます。
信頼アンカー
プロファイル
オンプレミスのサーバーにヘルパーツール (aws_signing_helper)を導入し、IAM Roles Anywhere を使用する
オンプレミスのサーバーにヘルパーツール (aws_signing_helper)を導入し、IAM Roles Anywhere を使用します。
aws_signing_helper は、以下の URL リンクに用意しています。
オンプレミスのサーバーにバイナリファイルを配置することにより、使用可能です。
必要に応じてパスを通してください。
Obtaining temporary security credentials from AWS Identity and Access Management Roles Anywhere - IAM Roles Anywhere
aws_signing_helper は、以下のように使用します。
./aws_signing_helper credential-process \ --certificate ./cert.pem \ --private-key ./private-key.pem \ --trust-anchor-arn $TA_ARN \ --profile-arn $PROFILE_ARN \ --role-arn $ExampleS3WriteRole_ARN
- --certificate
- エンドエンティティ証明書ファイルを指定します。
- --private-key
- 秘密鍵ファイルを指定します。
- --trust-anchor-arn
- 信頼アンカーのARNを指定します。
- --profile-arn
- IAM Roles Anywhere のプロファイルを指定します。
- --role-arn
- IAM Roles Anywhere のプロファイルに登録した IAM ロール (オンプレミスのサーバーが引き受ける IAM ロール)の ARN を指定します。
実行例です。
以下のように AWS クレデンシャルの設定ファイル (~/.aws/config )に記載することもできます。
[profile any] credential_process = ./aws_signing_helper credential-process --certificate /path/to/certificate.pem --private-key /path/to/private-key.pem --trust-anchor-arn <TA_ARN> --profile-arn <PROFILE_ARN> --role-arn <ExampleS3WriteRole_ARN> region = ap-northeast-1
IAM Roles Anywhere で発行したクレデンシャル(アクセスキー・シークレットアクセスキー・セッショントークン)を使用してみると、意図した通りに動きました。
権限のある S3 の参照は成功し、EC2 の参照は失敗しました。
IAM ロールの信頼ポリシーを書き換えると、認証に使用するエンドエンティティ証明書の内容と一致しなくなることも、確認してみます。
想定通り、アクセス拒否(AccessDeniedException)になりました。
まとめ
IAM Roles Anywhere を構築してみました。
認証の仕組みを理解してしまえば、難しくなさそうに感じました。
他。
OpenSSL 篇:
余談
先週は中央アルプスの稜線を歩いてきました。
気温が暖かく(マイナス1度くらい)、半袖で歩いていたら体を冷やしました。
身体を暖かくするのは大切ですね。
山本 哲也 (記事一覧)
カスタマーサクセス部のエンジニア。2024 Japan AWS Top Engineers に選んでもらいました。
今年の目標は Advanced Networking – Specialty と Machine Learning - Specialty を取得することです。
山を走るのが趣味です。今年の目標は 100 km と 100 mile を完走することです。 100 km は Gran Trail みなかみで完走しました。OSJ koumi 100 で 100 mile 砕け散りました。どこかで 100 mile やりたいです。
基本的にのんびりした性格です。座右の銘は「いつか着く」