[S3]クロスアカウント時のアップロード時の権限エラー[はまった] | DevelopersIO
コンニチハ、千葉です。 S3のクロスアカウント環境を構築したのですが、クロスアカウント上でアップロードしたファイルをダウンロードしたとろこと権限エラー(Access Denied)になってはまったので記しておきます。 事象 環境 クロスアカウントで S3 sync するための権限設定を参考に、IAMロールベースでクロスアカウントのアクセス設定をしました。 環境は以下となります。 これで、アカウントAのEC2からアカウントBのS3バケットを操作できるようになります。 具体的には、アカウントAのEC2からaws cp [ローカルファイル] s3://[アカウントBのS3バケット名]でファイルをアップロードしました。 権限が足りないエラー発生 アカウントBにファイルをアップロードできましたが、アカウントBにログインしS3にアップロードされたファイルを操作すると、 ファイル削除ができる それ以外の
![[S3]クロスアカウント時のアップロード時の権限エラー[はまった] | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/ae1831085634f040d8ea87c65585c41d4de216bc/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F05%2FAmazon_S3.png)
aws-auth ConfigMapをEKSクラスタにCodeシリーズで自動デプロイする仕組みを構築してみた | DevelopersIO
こんにちは、かたいなかです。 EKSをチームで運用する際に、EKSクラスタにアクセスする必要があるIAMユーザ/ロールが増えるたび、すでにアクセスできる状態になっている人に依頼してaws-authConfigMapをeditしてもらうというのは大変ですよね。 そこで今回は以下の図のように、Codeシリーズを使用してaws-authConfigMapのYAMLの変更が、Kubernetesのクラスタに自動で反映されるようにする方法をご紹介します。 おさらい：aws-authConfigMapとは aws-authConfigMapはIAMのユーザ/ロールをKubernetes内のユーザやロールに紐付けを定義します。EKSクラスタ作成者以外のIAMのユーザ/ロールは、このConfigMapに紐づけが定義されていないと、Kubernetesクラスタ内のリソースにアクセスすることができません。 具
[初心者向け]AWS CLIでMFA必須のスイッチロール先のS3にアクセスしてみた | DevelopersIO
こんにちは、平野です。 まだまだAWS初心者として勉強中の身なので、基礎的な内容ですが自分の中ではこれができたことでIAMについて理解が進んだので投稿させて頂きます。 課題 スイッチロールした先のS3のバケットの中身を再帰的に全てダウンロードしたいと思ったのですが、AWS CLIからではそのS3に接続できずに困っていました。 マネジメントコンソールからならバケットを見て個別にダウンロードもできるので、CLIでできないのはただ設定が足りないだけのはず、ということで設定を調べてやってみました。 マネジメントコンソールでの状況確認 まず状況の説明のためにマネジメントコンソールからアクセスした際の様子を確認します。 「cm-hirano.shigetoshi」というIAMユーザでログインします。このアカウントをアカウントAとします。 MFA必須の設定になっていますので、入力します。 無事ログインで
![[初心者向け]AWS CLIでMFA必須のスイッチロール先のS3にアクセスしてみた | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/495673edbefe7b7bc5e6e9e54b2565989b893342/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2013%2F09%2Faws1.png)
AWS再入門ブログリレー AWS Identity and Access Management (IAM)編 | DevelopersIO
ポリシーは基本的にIAM ユーザーやグループ、ロールにアタッチするため、暗黙的にプリンシパルが決定されるので、プリンシパルはあまり使いません。 プリンシパルを使用する場面はS3バケットやKMS CMKなどといったAWSリソースにポリシーをアタッチする場合に使用されます。 このAWSリソースに対してアタッチするポリシーのことをリソースベースのポリシーと言い、IAM ユーザーやグループ、ロールにアタッチするポリシーのことをアイデンティティベースのポリシーと呼びます。 アイデンティティベースのポリシーの場合はポリシーを作って満足してはいけません。 IAM ユーザーで認証をしてIAM ポリシーで認可を行いますが、両者が紐づいてはいません。 なのでIAM ユーザーに対して必要なポリシーをアタッチしましょう。 ポリシーの種類管理ポリシーとインラインポリシー アイデンティティベースのポリシーを設定する場
別アカウントのS3バケットを利用する手順 | DevelopersIO
AWS アカウントが分かれている (クロスアカウント) 環境で、S3 バケットを共有したいときってありますよね。 本番環境と開発環境で AWS アカウントが分かれている 自社のサービスを AWS 環境で提供していて、ユーザの AWS アカウントの S3 バケットを利用する などなど、企業内/企業間を問わず、利用する機会は少なくないように思います。しかしながら、「どうやって使うの？」とお悩みの方も同じように少なくないのではないでしょうか？私もついこの間まで、そう思っていた側の人です。今回、別アカウントの S3 バケットを使用する機会がありましたので、同じお悩みをお持ちの方に向けて、私が実施した手順についてシェアしたいと思います。 概要 今回の手順で最終的に出来上がる環境は、以下のとおりです。 アカウントA（アカウントID:111111111111） S3 バケットを所有しているアカウントです
EC2にIAMRole情報を渡すインスタンスプロファイルを知っていますか？ | DevelopersIO
ご機嫌いかがでしょうか、豊崎です。 AWSマネジメントコンソール（以降、AMC）から利用していると気づかない、 インスタンスプロファイルについて調べましたので、書いていきたいと思います。 インスタンスプロファイルってなに？ インスタンスプロファイルは IAM ロールのコンテナであり、インスタンスの起動時に EC2 インスタンスにロール情報を渡すために使用できます。 参考URL http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html 書いてある通り、IAMRoleを納めるための容器であり、EC2にアタッチする時に必要なコネクターの役割をします。 なぜインスタンスプロファイルを意識しないのか？ EC2に対してAWSリソースへの操作権限を与え
EC2 + IAM Role で供給されたクレデンシャルを環境変数として使う - Qiita
2016-12-09 14:15 追記 EC2 上の Docker コンテナ内からでも、AWS_ 環境変数を設定することなくインスタンスプロファイルが使えました。 AWS SDK は AWS_* 環境変数設定されてなかったら自動で http://169.254.169.254/latest/meta-data/... を叩いてクレデンシャルを取りに行きます。で、ホスト直実行でもコンテナ挟むのでもつなぎに行くネットワークは同じ AWS なので問題なくインスタンスプロファイルを取れるのでした。 したがって、この記事に書いてあるような手間をかける必要はありません… tl;dr AWS_SECURITY_TOKEN AWS_SESSION_TOKEN を忘れるな 2019-03-11 追記 awscli は AWS_SECURITY_TOKEN で実行できますが、 AWS SDK は AWS_SE
AWS再入門2018 Identity and Access Management（IAM）編 | DevelopersIO
成人の日を迎えた皆様おめでとうございます。自分の成人式は何年前だったか、考えないことにした池田です。 はじめに 今回はAWS各種サービスを利用していく上で重要な要素の１つであるIdentity and Access Management（IAM）について整理していきます。 前回に続いてAWS再入門2018と題して勝手にシリーズ化させていこうとしていますので、お付き合いいただけますと幸いです。 参考とした資料は2017年12月に「Identity and Access Management: The First Step in AWS Security」というタイトルで公開されたこちらのスライドになります。 もくじ IAMとは AWSにおけるIAM IAMユーザーとグループ IAMの認証と認可（Authentication & Authorization） IAMポリシーとは IAMの評価ロ
【基本おさらい】Amazon S3バケットに読み取り専用のポリシーをつけたAWS IAMポリシーをサクッと作る方法 | DevelopersIO
こんにちは、せーのです。恵方巻で顎が外れそうになり、病院一歩手前でしたが今月もブログ頑張りましょう。 最近基本操作についての記事が少ないので、今日はIAMポリシーの基本としてS3のアクセスをコントロールするポリシーの書き方をおさらいします。サクッと作れるように要点だけを押さえて細かい仕様を省いてみます。 基本を押さえる IAMポリシーの基本 まずIAMポリシーの基本を押さえます。IAMポリシーはJSON形式で記述し、書く項目も決まっています。基本部分は覚えてしまえば簡単ですので覚えてしまいましょう。 Version : ポリシー言語のバージョン。[2012-10-17]が最新 Statement : 設定項目の大項目。この中に全てのポリシーが書かれる。 Sid : ステートメント識別子。ユーザーが識別の為につける文字列なのでポリシー内でかぶってなければなんでもいい。 Effect : この
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 管理コンソールを社内認証と SSO 化させる #m3dev - Qiita
この記事は「エムスリー Advent Calendar 2015」の 5 日目の記事です。 IAM で個人ユーザとか作りたくない AWS といえば SDK や CLI で API 連携して色々と操作できるわけですが、一方で管理コンソールも使うことも多いかと思います。この管理コンソールへのアクセス権限の管理はどのようにされているでしょうか？もし逐一 IAM ユーザをつくって運用するとしたら、数十人規模になるとかなり煩雑ですね。 エムスリーの場合、2015 年現在ではオンプレで運用されているサービスの方が多くて、ほとんどのサービスがヘビーに AWS を使っているというわけではないのですが、とはいえ、マネージドサービスはある程度使っていますし、新しいサービスでは全面的に AWS を使っているものもあります。また、AWS アカウント（ルートアカウント）を Sandbox 環境、QA 環境、本番環境
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon ECR に特定 IAM ユーザからのみのアクセスを許可 - Qiita
Developers. IO 2018セッション「ビジネスを阻害しない！AWS アカウントの管理」で話しました #cmdevio2018 ｜ DevelopersIO