IAM ロールの PassRole と AssumeRole をもう二度と忘れないために絵を描いてみた | DevelopersIO
コンバンハ、千葉（幸）です。 皆さんは、 PassRole と AssumeRole についてきちんと理解ができていますか？どちらも IAM ロールに関するものですね。 私はカラダ（ボディ）の調子がいい時は思い出せるのですが、雨が降っている日や、ちょっと疲れて気を抜いた時にはすぐ分からなくなってしまいます。 ということで、イメージとして脳に刻み付けることによって忘れられなくしてやろうと思いました。 そこで出来上がったのが以下です。 間違えました。以下です。 あ、でもやっぱり忘れづらいのはこちらかもしれませんね。 どうですか？もう忘れられなくなりましたね？ 先にまとめ IAM ロールには以下ポリシーを設定できる アイデンティティベースポリシー Permissions boundary 信頼ポリシー AWS リソースに IAM ロールを引き渡す際には PassRole の権限が必要 PassR
はじめに AWSのアクセス制御サービスであるIAMについて、2022年7月時点での機能および使用法を、初学者でも理解しやすいことを心掛けてまとめました。 IAMをよく分からないまま適当に設定するとセキュリティ的にまずいので、これを機に設定を見直して頂き、セキュリティレベル向上に貢献できれば幸いです。 特に、後述するIAM設定手順は、AWSに登録して最初に実施すべき設定に相当するため、セキュリティに興味がなくとも一度は実施することをお勧めします。 また公式のベストプラクティスは丁寧にまとめたつもりなので、初学者以外でもAWSのセキュリティ確保に興味がある方は、ぜひご一読頂けると嬉しいです。 IAMとは 「Identity and Access Management」の略です。 公式ドキュメントによると、IAMは「誰」が「どのAWSのサービスやリソース」に「どのような条件」でアクセスできるかを
ログ・モニタリングのやること AWS CloudTrail の設定 CloudTrail は AWS リソースに関して「誰が」「いつ」「何に」対して「どうような」操作をしたのかのイベントを記録するサービスです。イベント履歴から 90 日間分のイベントを確認することはできますが、イベントログの長期保管の設定（証跡の作成を行い、S3 に保管）をしておくことで、トラブル発生時の解析やインシデント発生時の調査などに利用できます。 有料です（無料利用枠もあります）。 [YouTube] AWS CloudTrail を触ってみた CloudTrail Insights イベントを利用することで、機械学習により異常なアクティビティを検出することもできます。通常の操作で検出されることがあるため、始めに試してみて、あまり活用しないようであれば無効化を検討でも良いと思います。 イベントログは S3 と Cl
たびたびTweetしておりますが、2019年9月22日の技術書典7に、『AWSの薄い本 IAMのマニアックな話』という本を出展します。名前の通りAWS本ですが、IAMだけを取り扱っています。初の同人誌を引っさげて、技術書典デビューします。 IAM本の目的 書いた本はIAMの特化本ですが、何故IAMと聞かれるのでここに書いておきます。AWSが不正利用されて100万円の請求が来たというようなニュースが、たまにネットを駆け巡ることがあります。原因の多くがIAMのアクセスキーをGitHubに誤ってコミットしてしまい、そのキーを不正利用されたケースです。そういった事態を防ぐために正しくIAMを知って貰いたいのです。 IAMは、AWSの利用権限を管理する極めて重要な機能です。AWSには多種多様な機能があり、IAMはそれに応じて様々な記述方法で権限を設定できるようになっています。その分設定項目が多く、I
さて、皆様はIAMにどのようなイメージをお持ちでしょうか。プロジェクトに関わる複数人で1つのAWSアカウントを扱う時、各メンバーに配布するアカウントを作れる機能。そして、その気になればアカウントをグループ分けし、権限を厳密に管理できる機能。といったところかと思います。 上記のユースケースで出てきた主なエンティティ（要素）はUserとGroupですね。IAMのManagement Consoleで見てみると、IAMはこれらの他にRoleやIdentity Providerというエンティティによって構成されているようだ、ということがわかります。今日はRoleにフォーカスを当てて、その実態を詳しく理解します。 IAM Role IAM Roleを使うと、先に挙げたIAMのユースケースの他に、下記のようなことが出来るようになります。 IAM roles for EC2 instancesを使ってみ
概要 先日、非公式ながらGitHub ActionsのAWSアクションで以下のような面白い機能が発表されました。 よりわかりやすく嚙み砕くとこういうことです。 Circle CIやGitHub ActionsでAWSを使う場合は事前に環境変数にアクセスキーとシークレットキーを登録させてCIを動かしてきましたが、そのためにIAMユーザーを発行して鍵を管理するのは手間だったのでこれはいいアップデートです。 今回はTerraformとGitHub Actionsを組み合わせたCI/CDにこの機能を取り入れてGitHub ActionsにIAMロールを渡してEC2インスタンス構築のCI/CDを実装してみようと思います。 GitHub Actionsを用いたTerraformのCI/CD TerraformでAWSリソースをデプロイする際にGitHub ActionsやCircle CIでCI/CD
2019年11月11日にSecurity-JAWSで発表した資料です https://s-jaws.doorkeeper.jp/events/99569
皆さん、IAM使ってますか〜？ 今日は、IAMのベストプラクティスの中に呪縛のように存在する、最小権限をテーマに悩みを語ってみようと思います。 IAMでのセキュリティのベストプラクティス まずは、IAMのベストプラクティスの確認です。2020年7月現在では、17個存在しています。一番最後のビデオで説明するの唐突感以外は、どれも納得感がある内容で実践・遵守すべきです。 docs.aws.amazon.com AWS アカウントのルートユーザー アクセスキーをロックする 個々の IAM ユーザーの作成 IAM ユーザーへのアクセス許可を割り当てるためにグループを使用する 最小権限を付与する AWS 管理ポリシーを使用したアクセス許可の使用開始 インラインポリシーではなくカスタマー管理ポリシーを使用する アクセスレベルを使用して、IAM 権限を確認する ユーザーの強力なパスワードポリシーを設定
それぞれのフェーズの詳細は以下のようになります。 当該アクセスキーを利用した不正な操作が行われる 流出したアクセスキーを利用し以下の操作が行われました。APIレベルの操作です。一連の操作はスクリプト化されているように見受けられます。 CreateAccessKey 流出したアクセスキーを利用し新規のアクセスキーを作成 DeleteAccessKey 流出したアクセスキーを削除 CreateUser IAMユーザーを作成（権限不足により失敗） CreateKeyPair 新規のアクセスキーを利用しキーペアを作成 RunInstances 全リージョンでインスタンスを起動 各リージョンで20のインスタンスが立ちあがる（起動上限はデフォルトのまま） m5.24xlargeなどインスタンスサイズが大きいものが優先される その後、起動したインスタンスにて仮想通貨Moneroのマイニングが行われました
森永です。 今回は技術寄りの話ではなく、概念的な話です。 がっつりインフラエンジニアの方というよりは、情シスなどでAWSに関わるの非エンジニアの方向けに書いていきます。 AWSを利用する上ででてくる「アカウント」についてまとめてみました。 オンプレと何が違うの？、というお話をよく耳にしますので、オンプレとの対比を挟みながら説明していきます。 AWSで使用するアカウント AWSでは以下の3つのアカウントに大別されます。 OS（Linux/Windows）アカウント IAM AWSアカウント この中でさらに2つに大別でき、OSアカウントはOS以上のレイヤについて、IAMとAWSアカウントは物理やネットワークレイヤといったAWSで管理されるレイヤについて管理するアカウントになっています。 各アカウントについて、管理方針も含めてもう少し深くまとめていきます。 OSアカウント 特に説明はいらないかと
はじめに こんにちは、川原です。 AWSのIAMサービスでは、各AWSサービスへの操作をアクセス制御するために「ポリシー」という概念があります。 AWSのドキュメントを読んでいると、ポリシーにはいくつか種類があることに気付くかと思います。本ブログではそれらのポリシーについて整理してみたいと思います。 ポリシーの基本 ポリシーは基本的に、「誰が」「どのAWSサービスの」「どのリソースに対して」「どんな操作を」「許可する(許可しない)」、といったことをJSON形式で記述します。 記述したポリシーをユーザー(IAMユーザー、IAMグループ、IAMロール)や、AWSリソースに関連づけることで、アクセス制御を実現しています。 例えば、以下のJSONはAWS側で用意しているAmazonS3ReadOnlyAccessという名前のポリシーです(後述するユーザーベースポリシーのAWS管理ポリシーに該当)。
大栗です。 先程既存のEC2に対してIAM Roleを設定することができるようになりました！早速試してみます。 New! Attach an AWS IAM Role to an Existing Amazon EC2 Instance by Using the AWS CLI Attach an IAM role to your existing Amazon EC2 instance 2017年3月6日現在 Management ConsoleでもIAM Roleの設定が可能になっています。 [アップデート] EC2コンソールで既存のEC2インスタンスに対してIAM Roleをアタッチ、変更ができるようになりました IAM Roleとは？ IAM Roleとは、AWSのサービスに対してアクセス権限を付与する機能です。IAM Roleでは対象サービスのみにアクセス権限を設定できアクセスキ
![[アップデート]既存のEC2にIAM Roleを付与できるようになりました！ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/58278067871ebaae68a873315f4dd4b9b78f6b5a/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F05%2FAmazon_EC2.png)
はじめに こんにちは、虎塚です。 組織でAWSアカウントを利用する際には、担当者ごとにIAMユーザを払い出し、各ユーザが自分でMFA (Multi-Factor Authentication) を有効にすることが推奨されています。クラスメソッドでも、お客様の環境ごとにIAMユーザを作成し、MFAを設定していただくようにお願いしています。 ここで問題になるのが、IAMのポリシーです。IAMユーザ本人に自分自身のMFAを管理できるようにするには、どんなポリシーが適切なのでしょうか？ このテーマは、当ブログの過去記事でも何度か登場していますね。 一般のIAMユーザにMFAを設定してもらう方法 ｜ Developers.IO IAMによるAWS権限管理 – プロジェクトメンバーへの権限付与方針に潜む闇 ｜ Developers.IO 2015年8月現在、上記で紹介されたポリシーでは正常に動かなかっ
望月@シアトルです。 今日はAmazon S3を複数名で利用するときの、IAM権限制御に関するTIPSのご紹介です。 想定する環境 S3は安価かつ高耐久性のストレージとして、AWS上でシステムが稼働しているかどうかに関わらず利用することが可能です。また、単純な保存領域としてだけでなく、S3 Static Website Hostingと呼ばれる機能を利用すれば、S3にHTMLなどの静的ファイルを配置しておくだけで簡単にWEBサイトを作れます。 この機能により、可用性・対障害性の高いWEBサーバを非常に安価(〜10円/月)でホスティングできます。 Static Website Hostingを利用する時には、S3にファイルを配置するだけで外部への公開ができますが、気にしなければならないことの一つに権限の管理があります。S3へのアップロード権限はAWS Identity and Access
IAM の評価論理をやんわり押さえるセッション「やんわり押さえよう IAM の評価論理」で登壇しました #devio2021 | DevelopersIO
【やんわり】（副詞） ━ものやわらかであるさま。おだやかなさま。 （デジタル大辞泉より） コンバンハ、千葉（幸）です。 皆さんは IAM の評価論理って難しいと思っていませんか？ 実は…… … …… ……… その通り、難しいんです。 やれアインディティベースポリシーとリソースベースポリシーだの、アカウントをまたぐまたがないだの、ガードレールがどうだの、暗黙的だの明示的だの、覚えることがたくさんあって難しいです。 詳細な内容は必要に迫られたときに考えるとして、「だいたいこういうことでしょ」とやんわり理解する状態を本セッションでは目指していきます。 セッションの雰囲気 これが…… こうなる感じ雰囲気のセッションです。 セッションで学べること 章ごとにサマリを描きます。 1. IAM JSON ポリシー IAM のポリシータイプは 6 つあること IAM JSON ポリシーの構成要素として Ef
最小権限のIAM Policy作成にCloudFormationのコマンドが役立つ | DevelopersIO
最小権限のIAM Policyを作成するのって地味に面倒ですよね。以前私は、Route53ホストゾーンにDNSレコード作成するのに必要な最小権限のPolicyを作るため、権限ゼロの状態から始めて、権限不足エラーが出るたびに権限を足していくという力技でPolicyを作ったことがあります。 Route53ホストゾーンにDNSレコードをTerraformで作成するのに必要な最小権限 | DevelopersIO もうちょっとスマートなやり方が、CloudFormation(CFn)のコマンドを使うとできる場合があることを学んだのでレポートします。 aws cloudformation describe-type そのコマンドが、 aws cloudformation describe-typeです。--typeオプションでRESOURCEを指定して、 --type-nameでCFnのリソースタイ
矢口です。 みなさんはAWSのIAMをどのように管理されていますか？ グリーでは色々な要件からMiamというツールをforkして Subiam というツールを開発し利用しはじめました。 Subiamは既存のAWSアカウントのIAM運用を阻害せずにコードベースで安全なIAM管理を始めることのできるツールです。 https://github.com/gree/subiam 特徴 コードでIAMを管理できる 差分を自動検出して適用 IAM全体ではなく任意の範囲だけを切り取って管理でき、システム全体に影響を与えないよう配慮されている dryrunできる 現在の状態をユーザーが管理し保存しておく必要がない 複数AWSアカウントで扱いやすいようRole Nameなどを自分で定義でき共通にできる 既存ツールとの比較 ツールの優劣を示すものではなく、自分たちに必要であった要件についてのみ比較しています。
GitHub - iann0036/iamlive: Generate an IAM policy from AWS, Azure, or Google Cloud (GCP) calls using client-side monitoring (CSM) or embedded proxy
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
AWS IAM で障害が起こったらどうなるの？ AWS IAM のレジリエンス（復元力）に関する記述がドキュメントに追記されていた | DevelopersIO
コンバンハ、千葉（幸）です。 AWS サービスで広範囲の障害が起こったときにどう備えるか？は AWS を利用する上では避けて通れない課題です。 例えば Amazon EC2 であれば、アベイラビリティゾーン（AZ）単位での障害に備えてマルチ AZ 構成にしておく、リージョン単位の障害に備えて別リージョンにバックアップを退避させておく、などの構成が思いつきます。 では AWS IAM で障害が起こったときに備えてどうすべきか？改めて問われると難しい問題です。わたしはぼんやりと「そもそも障害が起こることはないんじゃないか？そもそも AWS IAM における障害って何？」という思いを抱いていました。 そんな折、いつものように AWS IAM のドキュメントの更新履歴を眺めていると IAM のレジリエンスに関する更新が行われていることに気がつきました。 Document history for I
あけましておめでとうございます。河内です。 数ヶ月前に aws-vault を使い始めて安全の高まりを感じるので紹介します。 AWSのサービス上では IAM Role をできるだけ使ってアクセスキーを使わないようにしていますが、ローカルでの開発時にIAMのアクセスキーを利用することはあります。 アクセスキーが漏れると困ったことになります。 本番環境で利用している AWS アカウントで漏れると、付与している権限次第では機密情報が漏洩したりサービスが壊される可能性があります。 また開発環境としてのみ利用しているAWSアカウントであっても、ビットコインのマイニングなどで容赦なくリソースを消費され高額な請求が来たりする可能性ががあります。 そのようなことが起きないようにアクセスキーは安全に管理する必要があります。 通常はAWS SDK のデフォルト参照先である ~/.aws/credentials
AWS IAM Identity Center において一時的なアクセス許可を与える仕組みを提供する Temporary Elevated Access Management (TEAM) ソリューションを試してみた | DevelopersIO
AWS IAM Identity Center において一時的なアクセス許可を与える仕組みを提供する Temporary Elevated Access Management (TEAM) ソリューションを試してみた AWS IAM Identity Center で一時的なアクセス許可を与える仕組みを提供するソリューション Temporary Elevated Access Management (TEAM) が aws-samples で公開されました。例えば、特定の AWS アカウントへの AdministratorAccess 権限のアクセスを利用者が申請し、上長が承認する、といった運用を実現できます。 AWS のブログでも TEAM の使い方が紹介されています。 本ブログでは TEAM ソリューションをデプロイし、AWS アカウントへの一時的なアクセスの申請と承認を試してみます。
Check! AWS Lambda を理解しよう ～ ２つの動作モデル (pushモデル/pullモデル) | iret.media
AWSサービスや独自アプリケーションから、AWS Lambda へイベント通知して、コードを実行する コード実行の順序は保証されない 大事そうな部分をクイック和訳: pushモデル In both these cases, you must grant Amazon S3 or the custom application permission to invoke a function on your behalf. You do this by creating an invocation role, discussed in the following section. (2つのユースケース図のについて)これらのケースでは、あなたは Amazon S3、またはカスタムアプリケーションに、ファンクションを実行するパーミッションを与える必要があります。これは、invocation role
よく訓練されたアップル信者、都元です。前回（昨日）はAWSのクレデンシャルとプリンシパルを整理し、「開発運用スタッフ」が利用するクレデンシャルについてプラクティスを整理しました。今回はAWS上で稼働する「システム」が利用するクレデンシャルについてのプラクティスを整理しましょう。 システムが利用するクレデンシャル システムが利用するとはどういうことかといいますと、要するに「ユーザがアップロードしたファイルをS3に保存する」だとか「S3バケットに保存されたファイル一覧を取得して表示する」だとか、そういう操作をするシステムを作ることです。このようなシステムでは、APIキーを利用しますね。 AWSのAPIキーには、これもまた大きく分けて2種類があります。 long lived credentials （永続キー） short lived session credentials （一時キー） 皆さん
[アップデート] 「最小権限の実装」が容易に！過去の CloudTrail イベントに基づいて IAM ポリシーを生成できるようになりました | DevelopersIO
コンバンハ、千葉（幸）です。 IAM Access Analyzer により、過去のアクティビティイベントに基づいて IAM ポリシーの生成ができるようになりました！ 「必要最小限の権限に絞る」というアプローチが取りやすくなりましたね。 激アツアップデートなので冗長構成で記事を書いています。（平たく言うと被った。）あわせてご参照ください。 何が嬉しいのか 「今はユーザーに広めの権限を与えているけど、必要な権限のみを与えるように絞っていきたいなぁ」 「必要な権限ってなんだろう。洗い出すのが難しいな」 「過去 30 日間で一通り必要な操作はしたから、それができれば十分だな」 「実際の操作を洗い出してそのままポリシーにしてくれたりしたらいいのに」 はい、それができるようになりました。 「最小権限の実装」は、 AWS を使用する上で遵守すべきベストプラクティスです。小さな権限から始めて徐々に必要な
下記GitHubにサンプルをアップロードしました。 https://github.com/teradonburi/CognitoUserAuthApiApproval サーバレスアーキテクチャとは サーバを運用する場合、大まかにわけて次の３つの選択肢が存在すると思います。 1. 自社でサーバを管理するケース（オンプレミス型） 2. クラウドサービスでサーバを管理してもらうケース（IaaSクラウド型） 3. クラウド上でビジネスロジックのみ記述して、必要な時だけサーバを稼働させ、スケールもクラウドサービスに任せるケース（サーバレス型） クラウドに依存するほど自前でカスタマイズできる自由度が減る代わりにサーバ運用コストが下がります。 ざっくり言ってしまうとオンプレのサーバは運用が大変なのとコストが高くて自社で持ちたくないのでクラウドのサーバを使いたい。クラウド型だと常時稼働していると運用コスト
Amazon Cognitoによる認証はSTSのweb identity federationとどう違うのか！？ | DevelopersIO
Amazon Cognitoによる認証はSTSのweb identity federationとどう違うのか！？ よく訓練されたアップル信者、都元です。少し前の話になりますが、2014年7月に Amazon Cognito がローンチしました。Cognitoは、モバイルアプリのためのサービスで、弊社ブログでも何度か取り上げています。 Cognitoの機能は、実は「Cognito Sync（複数デバイス間のデータ同期）」と「Cognito Identity（ID管理）」という2つのカテゴリに分類されます。もしかしたら、元々は別のプロダクトだった感もあります。というのも… APIドキュメントが別 Amazon Cognito Identity Amazon Cognito Sync AWS SDK for Javaのクライアント実装が別、Javaパッケージも別 com.amazonaws.se
[アップデート]IAMのアクセスアドバイザーでは、140以上のAWSサービスを対象に、アクションレベルで「最終アクセス日時」が確認できるようになりました | DevelopersIO
はじめに AWS IAMのアクセスアドバイザーでアクションレベルでの「最終アクセス日時」が確認できるサービス数は、140以上に増えました。 IAMのアクセスアドバイザーとは、IAMエンティティ（ユーザー、ロール、グループなど）が、AWSサービスごとの最終アクセス日時や、アクセス可能なAWSサービスを確認できる機能です。 従来は、IAMやLambda、S3、EC2などの一部のAWSサービス数のみ、アクションレベルで「最終アクセス日時」が確認できていました。 以前も以下の記事のようにアップデートがありました。 今回のアップデートでは、140以上のAWSサービスを対象に、アクションレベルで「最終アクセス日時」が確認できるようになりました。 これによって、IAMロールに指定された権限が実際に必要かどうかを判断し、不必要な権限を削除することで、IAMのベストプラクティスである「最小権限の原則」の実現
![[アップデート]IAMのアクセスアドバイザーでは、140以上のAWSサービスを対象に、アクションレベルで「最終アクセス日時」が確認できるようになりました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/bf00ad68b49f41acf5078ae9946ea858f9b1f486/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2023%2F08%2Faws-iam.png)
意外と知らない人がちらほらいたので、書き留めておく。 AWSとAPIとIAMについて 基本的にAWSの全てのサービス / リソースの操作はAPIによって行われます。 (Management Consoleの操作も内部的には全て同じAPIアクセス) S3への画像のuploadから、EC2 Instanceの増設/設定変更から、CloudWatchの参照、Support Caseの起票まで、あらゆる操作をAPIで行うことができるので、 単純なWeb Applicationだけでなく、オペレーション自動化など多種多様な用途で活用することになり、IAM User/Access Keyもあわせて複数用意することが多いと思います。 環境やサービスによってAWSのアカウント自体を分ける運用も多いと思いますが、そうなると扱うKeyの数は益々増えていきます。 AWS CLI 何かAWSのリソースを使ってもの
IAM の紹介ビデオ AWS トレーニングと認定では、IAM の概要について説明する 10 分の動画を提供しています。 AWS Identity and Access Managementへの概論 IAM の機能 IAM には、以下の機能があります。 AWS アカウント への共有アクセス パスワードやアクセスキーを共有しなくても、お客様の AWS アカウントのリソースを管理および使用するためのアクセス許可を他の人に付与できます。 詳細なアクセス権限 リソースごとに、ユーザーごとに、さまざまなアクセス権限を付与できます。例えば、一部のユーザーは、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Simple Storage Service (Amazon S3)、Amazon DynamoDB、Amazon Redshift、他の AWS のサ
サーバーレスアプリケーションから Amazon Aurora への IAM ロールベース認証 | Amazon Web Services
Amazon Web Services ブログ サーバーレスアプリケーションから Amazon Aurora への IAM ロールベース認証 ユーザー名とパスワードをアプリケーションに直接保存することはベストプラクティスではありません。セキュリティで保護されたアプリケーションでは、資格情報をプレーンテキストとして保存しないでください。ソリューションとして、AWS Identity and Access Management (IAM) ポリシーは、Amazon Aurora リソースを管理できるユーザーを決定するアクセス許可を割り当てることができます。たとえば、IAM を使用して、DB クラスター、タグリソース、またはセキュリティグループを作成、記述、変更、削除できるユーザーを決定できます。Amazon Aurora では、データベースユーザーを IAM ユーザーとロールに関連付けるこ
よく訓練されたアップル信者、都元です。本日は、IAMユーザやロール等に与えられるポリシーについて。 IAMは、AWSの操作に関するIDと権限を管理するためのサービスです。IAMユーザ等を作ることにより、そのIDで「誰が操作を行うのか」というアイデンティティを管理し、ポリシーによって「その主体はその操作を行う権限があるのか」を管理します。 関連エンティティの整理 IAMの世界には、ユーザ・グループ・ポリシー等のエンティティが出てきますので、まずはその関係を整理しましょう。 左の方はそこそこ理解しやすいと思います。ユーザはグループに所属でき、多対多の関係があります。ロールについては別エントリIAMロール徹底理解 〜 AssumeRoleの正体を御覧ください。 各ユーザ・グループ・ロールには、複数の「ポリシー」と呼ばれるものを0個または複数個付与できます。ポリシーというのは1つのJSONドキュメ
[小ネタ]Amazon Elasticsearch Service/Kibanaにユーザ認証でアクセスしてみる | DevelopersIO
まいど、大阪の市田です。 今回は、Amazon Elasticsearch Service（以下、Elasticsearch Serviceと表記）のKibanaに対して、ユーザ単位でアクセス制御する方法をご紹介します。 3行まとめ Kibanaにブラウザでアクセスする場合、IPアドレスではなくIAM Userで制御したい 追加でEC2とか立てたくない 「aws-es-kibana」というプロキシツールを使うと簡単 概要 Elasticsearch Serviceでは、IPアドレスの他にIAM Userやドメインによるアクセス制限を行えます。 IPアドレスによる制限の場合、そのIPを利用する人なら全員アクセスできてしまうので、要件によっては特定のユーザだけにアクセスを絞りたいと思うことがないでしょうか？ そこで今回は、KibanaへのブラウザアクセスをIAM User単位で制限 する方法を
![[小ネタ]Amazon Elasticsearch Service/Kibanaにユーザ認証でアクセスしてみる | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/505237ea0bf65f1e0f52f821a61adf066e99ba70/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2015%2F10%2Felasticsearch-service.png)
渡辺です。 2015年はAnsible, CodeDeploy, CodeCommitといった開発周りのプロダクトを色々と触ってきましたが、良い感じで整備されてきたなぁという印象があります。 環境構築からビルドまで全自動で走り、フルマネージドでサーバが動くというのは10年前どころか5年前でも中々難しいところでした。 数年後には「常識」になっているかもしれません。 さて、前回のエントリー（CodeCommitのGitリポジトリへの接続方法）では、IAMユーザを利用してCodeCommitのGitリポジトリに接続する方法を紹介しました。 CodeCommitのGitリポジトリへには、CodeCommitへのアクセス許可を持つIAMユーザを用意し、SSHの公開鍵を登録してSSH接続を行うか、アクセスキーを発行してHTTPS接続を行います。 これは、開発マシンなどから、CodeCommitのGit
新機能 – Amazon Cognito グループ、およびきめ細かなロールベースのアクセス制御 | Amazon Web Services
Amazon Web Services ブログ 新機能 – Amazon Cognito グループ、およびきめ細かなロールベースのアクセス制御 アプリケーションの構築における課題の 1 つは、ユーザー認証と管理に関する事柄です。この課題に直面しても、多くの開発者はアプリケーション用の別のユーザー ID と認証システムを構築したいとは考えていませんし、必要な場合を除いてユーザーにさらに別のアカウントを作成させたいとも思っていません。Amazon Cognito では、アプリケーションのデータとバックエンドシステムにアクセスするために、開発者がユーザーの ID、認証、および権限を簡単に管理できるようになっています。それに加えて、開発者がアプリケーションの異なるユーザーに異なる権限を割り当てるのを簡単にするサービス機能があればどんなによいでしょう。本日、Cognito ユーザープールがグループを
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 設定ファイルと認証情報ファイルの設定 頻繁に利用される構成設定および認証情報を AWS CLIが維持するファイルに保存することができます。 ファイルは profiles に分割されます。デフォルトでは、 AWS CLI はという名前のプロファイルにある設定を使用しますdefault。替わりの設定を使用するには、追加のプロファイルを作成して参照できます。 サポートされた環境変数のいずれかの設定を使用するか、あるいはコマンドラインパラメータを使用して、個別の設定を上書きすることもできます。構成設定の優先順位の詳細については、「を設定する AWS CLI」を参照してください。
IAM と連携する AWS のサービス - AWS Identity and Access Management
以下に一覧表示されている AWS のサービスは、アルファベット順にグループ化されています。また、サポートされる IAM の機能に関する情報を含んでいます。 サービス – サービスの名前を選択し、このサービスの IAM 認証とアクセスに関する AWS ドキュメントを表示できます。 アクション – ポリシーで個々のアクションを指定できます。サービスでこの機能がサポートされていない場合、[visual editor] (ビジュアルエディタ) で [All actions] (すべてのアクション) を選択します。JSON ポリシードキュメントでは、* 要素に Action を使用する必要があります。各サービスのアクションのリストについては、「AWS のサービスの アクション、リソース、および条件キー」を参照してください。 リソースレベルのアクセス許可 – ARN を使用してポリシーで個々のリソース
プリンシパルが AWS Management Console、AWS API、または AWS CLI を使用しようとすると、プリンシパルは AWS にリクエストを送信します。AWS サービスが、リクエストを受け取ると、AWS は、いくつかのステップを実行してリクエストの許可または拒否を決定します。 認証 – AWS は、必要に応じて、最初にリクエストを行ったプリンシパルを認証します。このステップは、匿名ユーザーからの一部のリクエストを許可するいくつかのサービス (Amazon S3 など) では不要です。 リクエストコンテキストの処理 – AWS は、リクエスト内で収集した情報を処理し、リクエストに適用するポリシーを決定します。 単一アカウント内のポリシーを評価する – AWS は、すべてのポリシータイプを評価します。ポリシータイプは、ポリシーを評価する順序に影響を与えます。 アカウント内
こんにちは。 サービスGの金谷です。 これまでIAMの設定を自分でやることがあまりなく、スイッチロールで何が起きているのか全然理解できていなかったのでまとめようと思います。 まず大前提 AWSアカウント≠ IAMユーザー です。 当然といえば当然なのですが別物です。 ざっくり説明するとAWSアカウントの中にIAMユーザーがいるといった形で、AWSアカウント＝ルートユーザーのようなイメージです。 私個人の経験としてはプライベートでAWSを学び触り始めたばかりのときは IAMを何も設定せずに他のサービスを触ったりしていましたが、通常は使用するべきではないです。 ちゃんとIAMユーザーを作成してそちらで作業するようにしましょう。 スイッチロールとは 名前の通りIAMロールを切り替える機能です。 アカウントを跨いだロールの切り替えも可能です。（というかこちらをメインに使います） 上図ではスイッチ元
このアクション、いまのポリシー設定で実行できる？ IAM Policy Simulator でお手軽に確認しちゃおう | DevelopersIO
コンバンハ、千葉（幸）です。 IAM ポリシーを設計・設定したのちには、きちんと意図通りに動作するか確認したいものです。とはいえ、リソースに変更を加えるようなアクションはなかなかテストしづらいですよね。 テスト用のリソースを作ったり消したりして対応する場面も多いかと思いますが、それすら許容されないケースもあります。そんな時にあくまで机上での動作のシミュレートができるのが IAM Policy Simulator です。 使い方を確認していきましょう。 目次 目次 IAM Policy Simulator の全体像 IAM Policy Simulator へのアクセス方法 IAM Policy Simulator に必要な権限 IAM Policy Simulator のモード シミュレートするポリシーの設定方法 AWS Organizations SCPs IAM Policies、Pe
IAM ポリシーエレメント: 変数 - AWS Identity and Access Management
序章 IAM ポリシーでは、アクセスを制御する特定のリソースに対して名前を指定することが多くのアクセションで許可されています。例えば、以下のポリシーでは、ユーザーは、marketing プロジェクトの S3 バケット DOC-EXAMPLE-BUCKET 内のオブジェクトの一覧表示、読み取り、および書き込みができます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": ["arn:aws:s3:::DOC-EXAMPLE-BUCKET"], "Condition": {"StringLike": {"s3:prefix": ["marketing/*"]}} }, { "Effect": "Allow", "Action": [ "s
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【2022年版ベストプラクティス】AWS IAMまとめ - Qiita
【資料公開】AWSアカウントで最初にやるべきこと 〜2022年6月版〜 | DevelopersIO
#技術書典 に出展する『AWSの薄い本 IAMのマニアックな話』はこんな本 - プログラマでありたい
IAMロール徹底理解 〜 AssumeRoleの正体 | DevelopersIO
GitHub ActionsにAWSクレデンシャル情報を渡さずにTerraformでCI/CDをやってみた
Security-JAWS IAMの設計を言語化する
AWS IAMの最小権限追求の旅 - プログラマでありたい
【実録】アクセスキー流出、攻撃者のとった行動とその対策 | DevelopersIO
非エンジニアにこそ知ってほしいAWSのアカウント管理 ｜ Developers.IO
AWS IAMポリシーを理解する | DevelopersIO
[アップデート]既存のEC2にIAM Roleを付与できるようになりました！ | DevelopersIO
IAMユーザ本人にMFAを管理してもらうためのIAMポリシー | DevelopersIO
【IAM TIPS】S3バケット毎に権限を分けるためのIAM権限設計 ｜ Developers.IO
Subiamを使いAWSのIAM管理をコードベースでおこなう | GREE Engineering
aws-vault でアクセスキーを安全に - FLINTERS Engineer's Blog
IAMによるAWS権限管理運用ベストプラクティス (2) | DevelopersIO
世界に先駆けてAWSサーバレスアーキテクチャでユーザ認証とAPI認可の実装をしてみた - Qiita
AWS CLI のprofileを簡単に切り替える - tail my trail
IAM とは - AWS Identity and Access Management
IAMによるAWS権限管理 – IAMポリシーの記述と評価論理 | DevelopersIO
CodeCommit のGitリポジトリにIAM Roleで接続する | DevelopersIO
設定ファイルと認証情報ファイルの設定 - AWS Command Line Interface
ポリシーの評価論理 - AWS Identity and Access Management
IAM初心者がAWS CLIでスイッチロールするまで | DevelopersIO