タグ付けされた質問 AWS Identity and Access Management
コンテンツの言語: 日本語
並べ替え 最新
以下に記載されている質問と回答を閲覧したり、フィルタリングして並べ替えて結果を絞り込んだりできます。
EC2にリモートデスクトップ接続できなくなり、オートメーションドキュメント(1)”AWSSupport-TroubleshootRDP”を実行し、FirewallをDisableにして解決をはかろうとしていますが、当該インスタンスにアタッチする上記オートメーション実行が可能なロールを作成するにあたって、そのロールに適用すべきポリシーはどれなのかがわかりません。また、このインスタンスに関しては、運用業務として(2)「再起動」や(3)「スナップショットの作成」をできるようにしておきたいのですが、これら(1)~(3)を可能とするポリシーはどれとどれを選択すべきでしょうか?
Cognito "ユーザープールのSAML IDプロバイダの作成と管理"
"SAML 2.0 IDP にデジタル署名用証明書を提供するには"
"idPがSAMLリクエストとログアウトリクエストの検証に使用できるパブリックキー”の原文は、"your idP can use to validate SAML logout requests" です。
SAMLでのAuthenticateRequestに対してもデジタル署名してくれるように読み取れますが、正しいですか? 仮にAzure SAML アプリケーション側で、SAML要求の署名検証を、このキーをアップロード設定して検証可能となることを意味しますか?
何でこんな翻訳なのでしょう?
アカウントに登録しているIAMユーザーについて、退任者のユーザーの登録管理方法を検討しています。
退任者のユーザーは、物理削除か、非アクティブ化(いわゆる論理削除)のどちらかの対応になるかと考えているのですが、それぞれのメリット、デメリットが整理しきれていないように思います。
また、CloudTrailの活用を前提に、物理削除を行った場合、管理上失われると良くない情報がなくなるかどうかわからず、苦慮しています。
オンプレミスでは論理削除が一般的ですが、AWSではどちらが主流なのか気になっています。
今のところ、以下のように検討しています。
前提
1. 運用の方針として、運用担当者のIAMユーザーには、(非アクティブ化以外の)ポリシーをアタッチしない。
2. 権限付与は、必要なポリシーをアタッチしたユーザーグループに追加することによって実現する。
3. 権限剥奪は、ユーザーグループから削除することによって実現する。
4. 各種の操作は、誤操作を排除するため可能な限りCLIで行う。
物理削除のメリット
1. 不要なアカウントが消されているので、IAMユーザーの棚卸に手間がかからない。
物理削除のデメリット
1. 削除後には、CloudTrail以外で追跡することができない。
2. 退任者が再び着任した際に、登録作業をはじめからやり直す必要がある。
非アクティブ化のメリット
1. CloudTrail以外で追跡することができる。
2. 退任者が再び着任した際に、登録作業をある程度省略できる。
非アクティブ化のデメリット
1. 不要なアカウントが残っているので、IAMユーザーの棚卸に手間がかかる。
2. 非アクティブ化のためのポリシーを管理しなければならない。
特定のタグ情報(キーと値)が付与されたリソース(EC2インスタンス、S3バケット)の操作が可能となる制御をポリシーで実装したいと考えております。
「ec2:ResourceTag」や「s3:ResourceTag」を使用することで実現できると想定しており、以下のポリシーを適用したところ、マネジメントコンソール上から全てのEC2インスタンス、S3バケットが表示されない状態となってしまいます。
エラーメッセージは「インスタンスデータ You are not authorized to perform this operation. の取得中にエラーが発生しました。」と表示されます。
IAMポリシーにて特定のタグ情報が付与されたリソースのみ操作可能とする制御の実現可否及び実現可能な場合、ポリシーの例をご教示頂けませんでしょうか。
なお、ポリシーは可能な限り簡素化して作成したく、Actionを細かく設定することは避けたいと考えております。
■適用したポリシー
{
"Version": "2012-10-17",
"Statement": \[
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/tag-key": "tag-value"
}
}
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/tag-key": "tag-value"
}
}
}
]
}
お世話になります。
起動テンプレートで以下のようなユーザーデータを持つテンプレートを作成しました。
```
aws s3 cp s3://<mybucket>/ /etc/ --recursive
echo 'finished!'
```
しかし、ログには
```
+ aws s3 cp s3://<mybucket>/ /etc/ --recursive
download failed: s3://<mybucket>/<file> to ../../../<file> Unable to locate credentials
```
と出て終了してしまっていました。
そのインスタンスにSSH接続して同じコマンドを叩くとダウンロードは正常にできるので
IAMロールは問題ないと思うのですが、解決策をご存じでしたら教えていただけますでしょうか。
ユーザフェデレーションを行うために python で lambda によるサービスを開発しようとしています。
この lambda はまず GetOpenIdTokenForDeveloperIdentity を呼び出して AWS 上の ID プールからトークンを取得し、それから AssumeRoleWithWebIdentity を呼び出します。しかしながら、lambda が AssumeRoleWithWebIdentity を呼び出そうと試みるとエラーになります。
```
"An error occurred (AccessDenied) when calling the AssumeRoleWithWebIdentity operation: Not authorized to perform sts:AssumeRoleWithWebIdentity
```
lambda のロールに付けられている信頼関係とポリシーは以下の通りです。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com",
"Federated": "cognito-identity.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:AssumeRoleWithWebIdentity"
]
}
]
}
```
```
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"lambda:InvokeFunction",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"cognito-identity:GetOpenIdTokenForDeveloperIdentity",
"sts:AssumeRoleWithWebIdentity"
],
"Resource": "*",
"Effect": "Allow"
}
]
}
```
これで AssumeRoleWithWebIdentity を呼び出すのに十分なポリシーと信頼関係が付けられているのか分かりますでしょうか。些細なことでもご教授いただけましたら幸甚です。
念の為、以下が lambda のコードの断片になります。
```
# 'provider_name' is a custom provider name set in an identity pool in AWS
cog_cli = boto3.client('cognito-identity')
cog_id_res = cog_cli.get_open_id_token_for_developer_identity(
IdentityPoolId=os.environ['IDENTITY_POOL_ID'],
Logins={
provider_name: user_id
}
)
sts_cli = boto3.client("sts")
sts_res = sts_cli.assume_role_with_web_identity(
RoleArn=os.environ['TARGET_ROLE_ARN'],
RoleSessionName=user_id,
WebIdentityToken=cog_id_res['Token']
)
```
クロスアカウント環境において、
accountA に構築したCloud9から
accountBに構築したCodeCommitへ統合を行いたいと考えています。
以下のドキュメントを参考にしているのですが、
"AWS Cloud9 と AWS CodeCommit を統合する"はシングルアカウントでの設定であり、
"AWS CodeCommit リポジトリにクロスアカウントアクセスを設定する"はローカルクライアントからの設定方法であり、Cloud9では利用できないようでした。
AWS Cloud9 と AWS CodeCommit を統合する
https://docs.aws.amazon.com/ja_jp/codecommit/latest/userguide/setting-up-ide-c9.html
AWS CodeCommit リポジトリにクロスアカウントアクセスを設定する
https://docs.aws.amazon.com/ja_jp/codecommit/latest/userguide/cross-account.html
実際に、"AWS CodeCommit リポジトリにクロスアカウントアクセスを設定する" を参考にローカルのWindows環境からは、CodeCommitにアクセスができたのですが、
同じユーザで作成、ログインしたCloud9からクロスアカウントのリポジトリにアクセスができず、
not foundとエラーが返ってきてしまいます。
!# Do not modify this file, if this file is modified it will not be updated. If the file is deleted, it will be recreated on Thu Aug 29 2019 07:59:46 GMT+0000 (UTC).
と書かれている、
~/.aws/credentials に
"AWS CodeCommit リポジトリにクロスアカウントアクセスを設定する" の
role_arn =を追記してもだめでした。
何か方法はありますでしょうか。
昨日(10/10)、I AMを使い始めました。
設定の際に一番最初に作成したグループやユーザー、ポリシーを消去してしまったことが原因なのか、
その後I AM内の各ページをクリックするもアクセス権限がないとエラーが出てしまいました。
ダッシュボードでは以下のエラー文です。
「リクエストの処理中に次のエラーが発生しました:
User: arn:aws:iam::アカウント番号:user/ユーザー名 is not authorized to perform: iam:GetAccountSummary on resource: *
User: arn:aws:iam::アカウント番号:user/ユーザー名 is not authorized to perform:
iam:ListAccountAliases on resource: *」
ポリシーを再設定しようにも以下のエラー文です。
「アクセス権限が必要です
このオペレーションを実行するための必要なアクセス権限がありません。管理者にアクセス権限を追加するよう依頼してください。 詳細はこちら。
User: arn:aws:iam::アカウント番号:user/ユーザー名 is not authorized to perform: iam:ListPolicies on resource: policy path /」と出てしまい、編集できません。
その他のページ、cloud9やS3にもアクセスできません。アカウントの削除すらできないため非常困っています。
ちなみに私はAWSのルートユーザーです。
個別案件のため、本来ならばAWSサポートに連絡すべきなのでしょうが、サポートページでも権限が無くサービスリストが選べないことで連絡できずにいます。英語版のForumも含め、丸一日調べても解決しなかったためここで相談させてください。
よろしくお願いいたします。
今日(2018/5/8)になってから、IAM の GenerateCredentialReport が Throttling エラーになり、
現時点(18時)でも状況が変わりません
CLIだと下記のような応答になります(SDKからAPIを呼んでも同じエラーになりますし、アカウント内
で同時にAPIを呼び出していることもありません)
aws iam generate-credential-report
An error occurred (Throttling) when calling the GenerateCredentialReport operation (reached max retries: 4): Rate exceeded
「Personal Health Dashboard」によれば、午後1時頃に発生したIAMの障害記録が載っており、すでに
解決済みとなっていますが、これの副作用でしょうか?
Edited by: kiyoshi4587 on May 8, 2018 2:34 AM
現在アカウント一つに対し、2名のユーザーを登録し、片方のアカウントでIOT_Coreにて外部デバイスから受信可能なThingを登録しました。
ところが、
①もう一方のユーザーでIOT_CoreにアクセスしてもThingが登録されておらず、
②別なPCでIOT_Coreを作成したユーザーでログインし直し、IOT_CoreにアクセスしてもThingが登録されていませんでした。
各ユーザーは同じ管理者権限のグループに属し、IAMロールもフルアクセス可能としています。
開発に伴い、同じものを各ユーザーが編集できるようにしたいのですが、リソース編集にはIAMロールの他に何か設定が必要なのでしょうか?
掲題の件について質問です。
背景としては社内研修用に払い出したAWSアカウントについて、rootメールアドレスによるログインができなくなっています。
以下のような状況です。
・root メールアドレスは MFAが有効になっている
・MFAデバイス(スマートフォン内の google authenticator)のハードが故障してしまっている
・root メールアドレスに対するパスワードリマインダーによるリセットをかけると、 MFAでのワンタイムパスの入力を求められる
・IAMユーザは1人も作成していない
・root メールアドレスのアクセスキー情報は持っていない
root でマネジメントコンソールへ入れればいいというよりは、別のユーザでマネジメントコンソールにログインないし、アクセスキー情報によるリソースへのアクセスができれば問題は解消します。
もし解決方法をご存じの方がいらっしゃいましたら教えていただけますと幸いです。