EC2インスタンスプロファイルによってAssumeRoleされた認証情報の有効期限は短くできるのでしょうか - ヤマムギ
「EC2インスタンスプロファイルによってAssumeRoleされた認証情報の有効期限を短くする」方法がわからなかったので、CLIで無理やり実験してみました。 結論 EC2インスタンスプロファイルに頼るのではなく、sts:AssumeRoleをCLIやSDKで実行して有効期限を指定してあげたほうがいいですね。 IAMロール S3:ListAllMyBucketsのみ許可したIAMロールを作ってEC2インスタンスに設定しました。 あとセッションマネージャー使いたいのでAWS管理ポリシーのAmazonSSMManagedInstanceCoreはアタッチしてます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" } ] }
IAM ロールの PassRole と AssumeRole をもう二度と忘れないために絵を描いてみた | DevelopersIO
コンバンハ、千葉（幸）です。 皆さんは、 PassRole と AssumeRole についてきちんと理解ができていますか？どちらも IAM ロールに関するものですね。 私はカラダ（ボディ）の調子がいい時は思い出せるのですが、雨が降っている日や、ちょっと疲れて気を抜いた時にはすぐ分からなくなってしまいます。 ということで、イメージとして脳に刻み付けることによって忘れられなくしてやろうと思いました。 そこで出来上がったのが以下です。 間違えました。以下です。 あ、でもやっぱり忘れづらいのはこちらかもしれませんね。 どうですか？もう忘れられなくなりましたね？ 先にまとめ IAM ロールには以下ポリシーを設定できる アイデンティティベースポリシー Permissions boundary 信頼ポリシー AWS リソースに IAM ロールを引き渡す際には PassRole の権限が必要 PassR
初めてのAssumeRole | DevelopersIO
まだまだ使ったことの無いAWSサービスが多い菅野です。 今回はサービスではないのですが、AssumeRoleという機能を初めて使ったのでまとめてみました。 案件としては別AWSアカウントに存在するS3バケットにファイルを保存する事が目的なのですが、 保存するだけでしたらバケットポリシーで別アカウントのIDを許可するという方法があります。 ただ、その方法だとファイルの所有者が「ファイルをアップロードしたAWSアカウント」になってしまいますので、 トラブルにならないように、AssuemRoleを使うことでファイルの所有者がS3バケットを持つアカウントとなるようにします。 今回の目標 別アカウントのS3バケットにファイルを保存する AssumeRoleにより権限の委譲を行い、S3バケットへの保存許可を得る 作業が完了した時には、以下のようなイメージになります 大まかな作業の流れ 【S3バケットを
SAML 2.0 フェデレーション - AWS Identity and Access Management
AWS は SAML 2.0 (Security Assertion Markup Language) を使用した ID フェデレーションをサポートします。これは、多くの ID プロバイダー (IdP) により使用されているオープンスタンダードです。この機能はフェデレーティッドシングルサインオン (SSO) を有効にします。したがって、組織内の全員について IAM ユーザーを作成しなくても、ユーザーは AWS Management Console にログインしたり、AWS API オペレーションを呼び出したりできるようになります。SAML を使用すると、カスタム ID プロキシコードの書き込みの代わりに IdP のサービスを使用できるため、AWS を使用してフェデレーションを構成するプロセスを簡素化できます。 IAM フェデレーションは次のユースケースをサポートします。 組織のユーザーまた
IAM ロール (AWS API) の切り替え - AWS Identity and Access Management
############################################################################### # function iam_create_user_assume_role # # Scenario to create an IAM user, create an IAM role, and apply the role to the user. # # "IAM access" permissions are needed to run this code. # "STS assume role" permissions are needed to run this code. (Note: It might be necessary to # create a custom policy). # # Returns: #
IAM ロール (AWS CLI) の切り替え - AWS Identity and Access Management
ロールは、必要な AWS リソースへのアクセスに使用できる一連のアクセス許可を指定します。その点では、AWS Identity and Access Management（IAM）のユーザーに似ています。ユーザーとしてサインインすると、特定の一連のアクセス許可が付与されます。ただし、ロールにはサインインされませんが、ユーザーとしてサインインした後でロールを切り替えることができます。こうすると、元のユーザーアクセス権限が一時的に無効になり、そのロールに割り当てられたアクセス権限が代わりに付与されます。ロールは、自身のアカウントのロールでも、他の AWS アカウント のロールでもかまいません。ロールとその利点、およびロールを作成して設定する方法については、「IAM ロール」および「IAM ロールの作成」を参照してください。ロールを引き受ける別の方法については、「IAM ロールを使用する」を参照
[AssumeRole] アクセスキーが漏洩しても被害が最小限になるIAMユーザでCloudFormationにデプロイする方法 | DevelopersIO
IAMユーザ & IAMロールを作成 デプロイ用のIAMユーザと付与するIAMポリシーについて このユーザ自身に与える権限は、AssumeRoleできる権限のみです。 そのため、万が一このIAMユーザのアクセスキーが流出しても、流出したアクセスキーでは実質何もできません。 デプロイ用のIAMユーザがAssumeRoleするIAMロールについて 「デプロイ用のIAMユーザ」がAssumeRoleする（引き受ける）「IAMロール」です。 今回作成するIAMロールには下記の権限を付与しますが、必要に応じて変更してください。 S3バケットの作成権限 S3オブジェクトの作成権限 お試しデプロイとしてAWS SAMを使うため、S3の権限も付与（Lambdaコードのアップロードをするため） CloudFormationのデプロイ準備に必要な権限 「CloudFormation用のIAMロール」はclou
![[AssumeRole] アクセスキーが漏洩しても被害が最小限になるIAMユーザでCloudFormationにデプロイする方法 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/3a9299c22c271be79f273b6db38d8ba6bc81bd1c/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2021%2F05%2F8823428add162ea6925215296ff8c67f.png)
一時的なセキュリティ認証情報のリクエスト - AWS Identity and Access Management
AWS STS API オペレーションから返されるセッショントークンのサイズは固定ではありません。最大サイズを仮定しないことを強くお勧めします。一般的なトークンのサイズは 4096 バイト未満ですが、変化する可能性があります。 AWS リージョンでの AWS STS の使用 AWS STS API 呼び出しは、グローバルエンドポイントにも、リージョンのエンドポイントの 1 つに対しても送信できます。より近くのエンドポイントを選択した場合、レイテンシーを軽減し、API 呼び出しのパフォーマンスが向上します。また、元のエンドポイントとの通信ができなくなった場合は、代替リージョンのエンドポイントに呼び出しを送信することもできます。各種 AWS SDK の 1 つを使用している場合、API コールを行う前に SDK メソッドを使用してリージョンを選択します。手動で HTTP API リクエストを組
AssumeRoleWithWebIdentity - AWS Security Token Service
Returns a set of temporary security credentials for users who have been authenticated in a mobile or web application with a web identity provider. Example providers include the OAuth 2.0 providers Login with Amazon and Facebook, or any OpenID Connect-compatible identity provider such as Google or Amazon Cognito federated identities. For mobile applications, we recommend that you use Amazon Cognito
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 STSのAssumeRoleを利用してS3にアップロードしてみる - Qiita
AWS STSのAssumeRoleを利用して一時的セキュリティ認証情報を取得してS3にアップロードしてみたので内容をメモしておきます。 なお、IAMロール徹底理解 〜 AssumeRoleの正体 ｜ Developers.IOがロールを理解するためにとても参考になります。 一時的セキュリティ認証情報について 一時的なセキュリティ認証情報は利用期限があるAWSを利用するための一時的な認証情報である。 一時的であるのでたとえ外部に漏れたとしても時間がたてば使えなくなる。 アプリに埋め込みされた認証情報が漏れる場合に比べて安全になる。 ロールの継承とフェデレーショントークンの取得について 今回行ったのはロールの継承だが、以下のようなフェデレーショントークンの取得でも一時的セキュリティ認証情報は取得できる。 AWS - 一時的セキュリティ認証情報を使って、特定のS3バケットにアップロードする -
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AssumeRole - AWS Security Token Service