IAMロール徹底理解 〜 AssumeRoleの正体 | DevelopersIO
さて、皆様はIAMにどのようなイメージをお持ちでしょうか。プロジェクトに関わる複数人で1つのAWSアカウントを扱う時、各メンバーに配布するアカウントを作れる機能。そして、その気になればアカウントをグループ分けし、権限を厳密に管理できる機能。といったところかと思います。 上記のユースケースで出てきた主なエンティティ（要素）はUserとGroupですね。IAMのManagement Consoleで見てみると、IAMはこれらの他にRoleやIdentity Providerというエンティティによって構成されているようだ、ということがわかります。今日はRoleにフォーカスを当てて、その実態を詳しく理解します。 IAM Role IAM Roleを使うと、先に挙げたIAMのユースケースの他に、下記のようなことが出来るようになります。 IAM roles for EC2 instancesを使ってみ
単一のAWSアカウントに潜む重大な危険 | POSTD
Amazon Webサービス（AWS）のアカウントは、AWSでビジネスを展開している人にとって非常に大事なものです。ですが、AWSアカウントをたった一つしかもっていない場合、重大なセキュリティの危険に直面することになるでしょう。何が問題なのか、そしてどうすれば解決できるのかを、この記事でご紹介したいと思います。 危険性をはらむデフォルト設定：単一のAWSアカウント 単一のAWSアカウントには、EC2仮想サーバ、S3バケット、RDSデータベースなどビジネスに必要な様々なリソースとともに、IAMユーザが含まれています。アカウントへのログイン方法は基本的に2通りあります。ユーザ名とパスワードを入力するAWS Management Console、またはCLIやSDKで用いられるAWSアクセス認証情報を使うのです。以下の図は、その仕組みを示したものです。 訳注 account「このアカウントにはI
OIDC フェデレーション - AWS Identity and Access Management
ワークフローを使用して Amazon S3 や DynamoDB にアクセスする GitHub Actions などの AWS リソースにアクセスするアプリケーションを作成するとします。 このようなワークフローを作成する場合、AWS アクセスキーで署名される必要のある AWS サービスに対してリクエストを実行します。ただし、AWS 外部のアプリケーションには AWS 認証情報を長期間保存しないことを強くお勧めします。代わりに、「OIDC フェデレーション」を使用して、必要に応じて一時的な AWS セキュリティ認証情報を動的に要求するようにアプリケーションを設定します。提供される一時的な認証情報は、アプリケーションで必要とされるタスクの実行に必要なアクセス許可のみを持つ AWS ロールにマッピングされます。 OIDC フェデレーションを使用すると、カスタムサインインコードを作成したり独自のユ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
