| 雑記 |
Visual Basic 中学校 > 雑記 >
2020/4/11
この記事が対象とする製品・バージョン
| Azure | × | 対象外です。 | |
| AWS | ◎ | 対象です。 | |
| GCP | × | 対象外です。 | |
| Visual Studio | × | 対象外です。 |
目次
この記事ではローカル環境にAWSの認証情報を設定する５つの方法を説明します。
この認証情報はツールやAPIでローカル環境からAWSを操作するときに使用するものです。
お勧めは方法１です。よくわからない人は方法１を採用してください。
認証情報の実体はアクセスキーと呼ばれるランダムな文字列の組み合わせです。
アクセスキーを取得する方法は別の記事で説明しています。→ AWSでアクセスキーを取得する方法
アクセスキーはAWSのアカウントと結びついており、アクセスする対象のアカウントを指定する効果もあります。
AWSでは複数の方法を使って認証情報を取得できるようになっており、柔軟で便利ですが初心者にはわかりにくくなってしまっています。
以下に簡単な図を示します。
Amazonは多くの場合、共有認証情報ファイルと呼ばれるファイルに認証情報を設定することを推奨しています。
このファイルを使わずに環境変数やその他の方法で認証情報を設定することもできます。
共有認証情報ファイルは通常 credentials という名前のファイルです。このファイルは拡張子はありませんがテキストファイルです。 このファイルには複数の認証情報を登録できます。いろいろな立場でAWSにアクセスする場合には便利です。それぞれの認証情報を「プロファイル」と呼びます。 もっとも単純な場合 default という名前のプロファイルが１つだけ保存されています。(最初にdefaultプロファイルを作成する方法は方法１参照)。 default は特別な名前で、ツールやプログラムでプロファイル名を指定しなかった場合、この default プロファイルに記録されている認証情報が使用されます。
共有認証情報ファイル(creadentials)は、Windowsの場合、既定では %UserProfile%\.aws フォルダー内にあります。(たとえば、 C:\Users\rucio\.aws です。) |
この記事では開発者の端末などAWS外にあるサーバーなどの環境からAWSにアクセスする場合の認証情報の取り扱いを前提にしています。
EC2内の環境から同じアカウントのAWSのサービスにアクセスする場合は、IAMロールを使ってアクセス権限を付与することを第一に検討してください。
参考：Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用してアクセス許可を付与する
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html
AWS CLIのAWS configureコマンドを使用して、デフォルトの認証情報を共有認証情報ファイルに書き込むことができます。おそらくこの方法が最も一般的なのではないかと思います。
AWS CLIはAmazonにより提供されてるAWS用の公式コマンドラインツールで下記の場所からインストールできます。
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-cliv2.html
AWS CLIはポート 443 (通常 https 通信で使用されるポート)を使って、AWSにアクセスします。そのためAWS CLIを使う環境はポート443でAWSにアクセスできる必要があります。 企業内部のネットワークなどではプロキシーが設定されていて直接AWSにアクセスできない場合があります。その場合は、 HTTP プロキシを使用する で説明している手順でAWS CLIが正しいプロキシーを使って通信するように設定する必要があります。 |
AWS CLIがインストールされている場合、次のコマンドでdefaultプロファイルの認証情報を設定できます。
このコマンドを入力するとアクセスキーIDとシークレットアクセスキーなど４つの情報を入力するように順番に促されます。
アクセスキーIDとシークレットアクセスキーをまだ取得していない場合は、AWSでアクセスキーを取得する方法 の手順で先に取得しておいてください。
たとてば、次のように入力します。
[None]というのは、現在は何も設定されていないという意味です。もう１度aws configureを実行すると、今度は、[None]の変わりに前回設定した設定値が一部をマスクした形で表示され、何も入力しないでEnterを押すと、その値を変更しないという意味になります。
機密性の高い情報は credentials ファイルに保存され、機密性の低い情報は config ファイルに保存されます。
default以外のプロファイルを設定するには、次のコマンドを使用します。
特に必要がなければdefault以外のプロファイルを設定する必要はありません。
この例では test という名前のプロファイルを設定します。
後は、defaultの場合と同じです。
AWS CLIのコマンドは既定では default プロファイルを使って実行されます。たとえば、s3バケットの一覧を表示するaws s3 ls はdefaultプロファイルで設定されているアクセスキーが登録されているアカウントのs3バケットの一覧を取得します。 defaultでないプロファイルを指定する場合、コマンドごとに --profile プロファイル名 を指定します。たとえば、 testプロファイルを使ってs3バケットの一覧を表示するには aws s3 ls --profile test とします。 |
認証情報が正しく設定されている確認するには、コマンドを実行します。
ユーザーのロールによって実行できるコマンドが違うので、すべての場合に利用できるコマンドを私は知りません。
たとえば、権限があれば次のコマンドで、アクセスキーが登録されているアカウント名が表示されます。
他の気軽な例では次のコマンドで対象のアカウントのS3バケットの一覧が表示されればOKというものもあります。S3に適切な権限がなければこのコマンドは失敗します。
credentialsファイルをメモ帳で開いて直接値を書き込むこともできます。
この方法は非推奨だと思いますが、メモ帳だけあればできる点で手軽です。
冒頭にも書きましたが、共有認証情報ファイルは、Windowsの場合、既定では %UserProfile%\.aws フォルダー内にあります。(たとえば、 C:\Users\rucio\.aws です。)
このファイルは拡張子はありませんが、通常のテキストファイルでメモ帳でも開くことができます。>
認証情報ファイルは ini 形式で次の構造になっています。
| [プロファイル名1] aws_access_key_id = アクセスキーID aws_secret_access_key = シークレットアクセスー [プロファイル名2] aws_access_key_id = アクセスキーID aws_secret_access_key = シークレットアクセスー ･･･ |
実際の例：この例では、defaultプロファイルだけが設定されています。
| [default] aws_access_key_id = AKIAIOSFODNN7EXAMPLE aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY |
※アクセスキーIDとシークレットアクセスキー以外の情報が書き込まれる場合もあります。
自分で自分でこの構造にしたがってプロファイル名やアクセスキーID・シークレットアクセスキーを設定して保存すれば認証情報を登録できます。
AWS SDKを使うとVBやC#などのプログラムから認証情報の書き込みができます。
AWSの共有認証情報ファイルの読み書き の ２－５．プロファイルの新規登録 でプログラム例を紹介しています。
アクセスキーIDとシークレットアクセスキーを以下の環境変数に保存することで認証情報を設定することもできます。
AWS_ACCESS_KEY_ID ：アクセスキーIDを設定します。
AWS_SECRET_ACCESS_KEY ： シークレットアクセスキーIDを設定します。
ツールやAWS SDKを使うプログラムは自動的にこの環境変数を参照し、何か設定されていればその認証情報を使用します。
Windowsの場合、OSレベルの環境変数にはシステム環境変数とユーザー環境変数の２種類があり、どちらを設定してもOKです。
具体的な設定方法はここでは割愛しますので、インターネットで検索等してください。
参考：環境変数の使用
https://docs.aws.amazon.com/ja_jp/credref/latest/refdocs/environment-variables.html
環境変数には そのプログラムが動いているときに、そのプログラム内でのみ有効な環境変数(プロセスレベルの環境変数)もあります。
このタイプの環境変数はプログラムの実行が終了すると自動的に破棄されます。
これを利用してAWSの認証情報を設定することもできます。
設定すべき環境変数は方法４と同じ以下の２つです。
AWS_ACCESS_KEY_ID ：アクセスキーIDを設定します。
AWS_SECRET_ACCESS_KEY ： シークレットアクセスキーIDを設定します。
VBやC#などの.NET場合、プロセスレベルの環境変数を設定するには Environment.SetEnvironmentVariable メソッドを使用します。
以下にVBの例を示します。
Environment.SetEnvironmentVariable("AWS_ACCESS_KEY_ID", "AKIAIOSFODNN7EXAMPLE") Environment.SetEnvironmentVariable("AWS_SECRET_ACCESS_KEY", "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY") |
シングルサインオンの場合はより複雑な仕組みを使用しますが、認証情報を使用してAWSにアクセスする構造は変わりません。
わかりにくければ、AWSやAzureやその他いろいろのサービスの認証情報がばらばらになっている企業を想像してください。企業ではたくさんのサービスを利用します。サービスごとに異なるユーザーIDとパスワードまたはアクセスキーを使用してログインすることになってしまいます。ユーザーが退職したらどうなるでしょうか？そのユーザーが使っていたいろいろなサービスのユーザーIDを無効化しなければなりません。ユーザーも不便ですし、会社も不便です。１つの認証情報で全部のサービスを使うという便利さがわかりますよね。つまり、AWSにログインするのにも、AWSのアクセスキーを意識せず企業が管理しているユーザー情報でアクセスしたいというのがシングルサインオンなのです。もちろん、これを管理するITの担当者は企業内のID管理とAWSなどのサービスを結びつける設定や運用をする必要はあります。 企業は自前でユーザーIDを管理して認証プロバイダーを持っている場合もありますが、最近(2020年4月時点)ではこのあたりもクラウド化されており、AzureADやOkta、Akamai EAAなどを使用するケースも増えてきているようです。AWSはこれらと連動したシングルサインも可能です。 |
シングルサインオンではアクセスキーに加えてセッショントークンなどの情報も認証情報として保存されます。自動的に一時的に有効なアクセスキーが生成され、通常１時間で期限切れになります。
どのようなツールを使用してシングルサインオンするかによって具体的に何が起こるかは変わります。
シングルサインオンでアクセスするたびに、共有認証情報ファイルの認証情報が更新される場合もあります。(saml2awsというツールはこのタイプで、共有認証情報ファイルに saml という名前のプロファイルを作成します。)
参考
AWS シングルサインオン を使用するための AWS CLI の設定 (aws configure sso)
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-sso.html
外部プロセスを使用した認証情報の調達
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-sourcing-external.html
saml2aws
https://github.com/Versent/saml2aws
ツールやプログラムによって流儀が異なることがありえますが、ほとんどの場合、何もしないでツールやプログラムを実行すると自動的に共有認証情報ファイルのdefaultプロファイルを読み取るか、環境変数を読み取ってAWSにアクセスすることになります。
「自動的」というところがポイントで、簡単・便利ではありますが、初心者には何が起こっているのかよくわからないように感じられるかもしれません。
たとえば、AWS CLIが使えるなら「aws s3 ls」を実行すると、自動的に共有認証情報ファイルのdefaultプロファイルを読み取って、そこに記載されているアクセスキーを使ってAWSにアクセスします。アクセスキーはアカウントと結びついているため、対象のアカウントもこれで特定されます。結果、ユーザーに権限があれば、そのアカウントのS3バケットの一覧を取得できます。
VBやC#などの.NETで明示的に共有認証情報ファイルのプロファイル名を指定して認証情報を取得してAWSにアクセスする例を 認証情報を使ってAWSにアクセスする例 に記載しています。
