タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
俺達はいつまでも立ち尽くし見つめていた━━━ 数多の IAM ロールが移ろうように連鎖していく、そのさまを。 コンバンハ、「 IAM ロールはお面」おじさんです。 この世で最も大切なもの、それは繋がりであり、そして連なりですよね。 ということで、早速 IAM ロールで 10 連鎖してみました。 いや、せっかくなので 100 連鎖くらい行ってみましょうか。そうしましょう。興奮してきたな。 まとめ IAM ロールはそんな連鎖させるようなもんじゃない。 手始めに IAM ロールを 101 個作ろう 早速、 100 連鎖のために IAM ロールを 101 個作ります。 「 100 連鎖なのに 101 個なの?」と思うかもしれませんが、ヤマタノオロチの「股(首と首の間)」は 7 個しかありませんよね。(「岐」は 8 個あるんですけどね。)それと同じです。 101 個くらいの数なら「温かみのある手作業
コンバンハ、千葉(幸)です。 2021/4/27 に、JAWS-UG 初心者支部 #36 が しくじり LT というテーマで開催されました。 イベントの概要はこちら。 AWS初心者がやってしまいがちな失敗談を募集します。 過去の失敗事例 初心者が落ち入りそうな事例 初心者が不安に感じそうだけど、XXすれば大丈夫だよ。というセーフティネット的な事例 ハンズオンで高額請求きちゃった事例 失敗は成功のもと!! みなさんの失敗例を、活かして頂ける場になれば幸いです!! 次回以降のハンズオン初心者のアドバイスになるネタがあれば嬉しいです!! ホットなしくじりを持つ AWS 初心者のわたしは、ここぞとばかりに申し込み、登壇することにしました。 プロローグ やぁ、僕はどこにでもいる平凡なエンジニア。ある日 急に、IAM ロールを 1000 個作りたいな、って思ったんだ。みんなもきっとそんなこと、あるよね
こんにちは ! テクニカルトレーナーの杉本圭太です ! 最近読んで面白かった漫画は「あかねさす柘榴の都」と「クジマ歌えば家ほろろ」です。 今回は IAM ロールの説明を、私なりに感じた「理解する時につまずきやすい部分」を紹介する形式でお伝えします ! これは自身の経験やトレーニングの受講者からよくいただく相談などを踏まえたものなので、今まで IAM ロールの説明を聞いたり読んだりしてきたけどいまいちピンときていない方に、ぜひモヤッとを解消していただきたいです ( ・∀・)=b というのも、私は業務でお客様に AWS の様々なトレーニング を提供しているのですが、AWS Identity and Access Management (IAM) について説明をした後に「トレーニングを受講したことで、今まで難しいと感じていた IAM ロールを理解できた !」と言っていただくことがあります。そのた
今回は S3 バケットへのアクセスを特定 IAM ロールからのみに限定して利用する機会がありましたので、設定方法と検討したあれこれをご紹介します。 やりたいこと 構成図はこんな感じ 前提条件 IAM ロールと S3 バケットは同一アカウントに存在する IAM ロールには S3 を管理する権限がアタッチされている 今回は AmazonS3FullAccess ポリシーをアタッチしています NotPrincipal でやってみる 「特定 IAM ロール以外は制限する」という考え方でパッと思いつくのは、以下のような NotPrincipal で制限する方法かと思います。 バケットポリシー { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "NotPrincipal": { "AWS": "arn:aws:iam::xxxx
Amazon Web Services ブログ Kubernetes サービスアカウントに対するきめ細やかな IAM ロール割り当ての紹介 本投稿は Micah Hausler と Michael Hausenblas による記事を翻訳したものです AWS ではお客様のニーズに最優先にフォーカスしています。Amazon EKS におけるアクセス権制御に関して、みなさまは「パブリックコンテナロードマップ」の Issue #23 にて EKS でのきめ細かい IAM ロールの利用方法 を求められていました。このニーズに応えるため、コミュニティでは kube2iam、kiam や Zalando’s IAM controller といったいくつかのオープンソースソリューションが登場しました。これらのソリューションは素晴らしいプロダクトであるだけでなく、それぞれのアプローチの要件及び制約は何なのか
ども、ゲストのNTT東日本 大瀧です。 本日IAMロールAnywhereがリリースされました。IAMロールAnywhereは、AWSの認証基盤であるIAMの認証をPKI(公開鍵基盤)に外出しできる仕組みです。本ブログでは、手軽に試せるPKIとしてHashicorp Vaultを試す様子をご紹介します。 動作確認環境 OS : Ubuntu 20.04.4 LTS Vault : バージョン v1.11.0 AWS : 東京リージョン 1. Hashicorp Vaultのセットアップ まずはPKIのCA(認証局)となるVaultサーバーを立ち上げます。Vaultのダウンロードページの [Linux] - [LINUX BINARY DOWNLOAD]で Amd64 のリンクをコピーし、 wget の引数にしてダウンロードします。 $ wget https://releases.hashic
はじめに マルチアカウント環境ではIAM Identity Centerを使ってメンバーアカウントへログインすることが多いかと思います。 今回は特定のIAM Identity CenterユーザーのみAssumeRoleできるIAMロールを作成してみました。 前提 この記事ではマルチアカウント環境を前提としているため、以下については既に有効化・作成されているものとして進めます。 Control Tower or Organizations IAM Identity Center メンバーアカウントへログインできるIAM Identity Centerユーザー IAM Identity Centerユーザーが利用するアクセス許可セット 今回は以下2つのIAM Identity Centerユーザーを作成して、Administorator権限のアクセス許可セットでログインしています。 User
IAMユーザー/IAMロールの実際の操作履歴からIAMポリシーが生成可能になりました。理想(最小権限の原則)と、現実(実運用)のギャップを埋めるのにかなり役立ちそうです。 ご参考 IAM Access Analyzer makes it easier to implement least privilege permissions by generating IAM policies based on access activity IAM Access Analyzer makes it easier to implement least privilege permissions by generating IAM policies based on access activity Generate policies based on access activity - Things
コンバンハ、IAM 評価論理おじさん(幸)です。 先日、リソースベースポリシーの Principal 要素で指定するプリンシパルごとの挙動の違いが AWS ドキュメントに記載されました。 ドキュメントの追記内容をざっくり表したのが以下図で、囲っている部分が IAM ロールと IAM ロールを引き受けたセッション(ロールセッション)の差異を表しています。 リソースベースポリシーでロールセッションを直接許可している場合は、Permissions boundary やセッションポリシーの暗黙的な拒否が評価対象にならないということが判明し、とても満足な更新内容でした。 とは言え、ここで示されているのは以下のパターンにおける挙動です。 同一アカウントでのアクセス アイデンティティベースポリシーで許可なし Permissions boundary(アクセス許可の境界)がアタッチされており許可なし セッ
EKS (Elastic Kubernetes Service) のアップデート「IAM Roles for Service Accounts」が発表されました。概要の説明とチュートリアルを行った際の流れをご紹介します。 みなさん、こんにちは! AWS事業本部の青柳@福岡オフィスです。 AWSのマネージドKubernetesサービスである「EKS」(Amazon Elastic Kubernetes Service) に、多くの人が待望していた (かもしれない) 機能がついに追加されました! Amazon EKS Adds Support to Assign IAM Permissions to Kubernetes Service Accounts タイトルを直訳すると「Amazon EKSがIAMアクセス許可をKubernetesサービスアカウントへ割り当てるサポートを追加」です。 今
こんにちは!コンサル部のinomaso(@inomasosan)です。 前回と前々回でGitHub ActionsからECSのCI/CDやIAMポリシーの最小権限作成を試してみました。 [初心者向け] GitHub ActionsからECS FargateにCI/CDしてみた GitHub ActionsからECSとECRへのCI/CDを最小権限で実行したい 今回はGitHub ActionsでAWSの一時的なクレデンシャル(アクセスキーID、シークレットアクセスキー)を利用したいので、IAMユーザーの代わりにOIDCプロバイダとIAMロールを設定していきます。 IAMユーザーのクレデンシャルだとダメなの? IAMユーザーで発行したクレデンシャルは永続的に利用可能です。 GitHubではAWSのクレデンシャルをSecretsにより秘匿化できますが、AWS外のサービスに永続的なクレデンシャル
EC2インスタンスやLambda関数にはIAMロールをアタッチすることができます。 ゆるいIAMポリシーを採用していると、STS 可能な任意のIAMロールを利用できてしまいます。 この問題を解決するために、IAMロールとロールを利用するAWSサービスのペアを制限する方法を紹介します。 AWSサービスに渡すIAMロールを制限する 例えば、EC2 インスタンスに特定のIAMロールのみアタッチ出来るようにするには、次のように定義します。 { "Version": "2012-10-17", "Statement": [ { "Sid": "IAMPassRoleForEC2", "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": "arn:aws:iam::12345:role/EC2Role", "Condition": {
IAM ロールの信頼ポリシーに設定する外部 ID(sts:ExternalI) について勉強しました。 こんにちは、岩城です。 3rd Party 製の SaaS と AWS アカウントを連携する際、専用の IAM ロールの作成と作成したロールに以下のような信頼ポリシーを定義して、特定の AWS アカウントから AssumeRole を許可することがあります。 { "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::xxxxxxxxxxxx:iamuser" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "xxx
[アップデート] AWS Transfer Family の認証要素にソース IP が利用できるようになったので、ソース IP に応じた IAM ロールの切り替えをやってみた 先日のアップデートで AWS Transfer Family のカスタム ID プロバイダー利用時に認証要素としてソース IP が利用できるようになりました。 AWS Transfer Family enables Source IP as a factor for authorization 何がうれしいのか? セキュリティグループでえぇんちゃうの? このアップデートを最初に見たときの感想です。 AWS Transfer for SFTP がリリースされた当初はソース IP による制限が欲しい!という声をたくさん聞きましたが VPC エンドポイントに対応、EIP に対応などのアップデートにより送信元の制限はすでに実
1. IAMと拒否ポリシーの概要 IAM(Identity and Access Management)とは Google CloudのIAMポリシーは、デフォルトでは許可を指定するポリシーです。 よって、リソースに対するユーザーやグループ、サービスアカウントへの権限付与を明示的に許可することになります。 IAMロール周りの記事は過去に短く解説しているので、拝見下さい。 【Google Cloud:IAMのイメージについてざっくりまとめてみた】 拒否ポリシーとは IAMポリシーに対して、拒否ポリシーはこの挙動を反転させるものです。 つまり、ユーザーが特定のリソースに対して行うことができる操作を明示的に制限(拒否)します。 【公式から引用】 Identity and Access Management(IAM)拒否ポリシーを使用すると、Google Cloud リソースへのアクセスにガードレ
はじめに 先日、AWSのアクセス制御についてのプレゼンを行いました。 その際、ポリシーが増える場合、どのように対応すれば良いですか?という質問を頂きました。 そこで、ポリシーを管理するためのIAMロールの説明がうまくできませんでした。 ポリシーやロールは普段から触ることも多いですが、そのメリットをちゃん理解できていなかったことを自覚しました。 そこで、AWSのIAMロール周りのことを聞かれて「ドキッ」とする、そんな私のような方は是非読んでみて下さい。 概要 この記事ではIAMロールの利点に焦点を当てているので、あまり細かい仕組みの説明はしておりませんので、あしからず。 ポリシー ポリシーってなに? そもそも、ポリシーってなんでしょう? ポリシーがあって何がいいんでしょう? では、まずポリシーがない状況を考えましょう。 ポリシー(権限)が無いと、誰でも、いつでも、なんでも、操作できるという状
ECS コンテナインスタンス IAMロール コンテナを動作させるホストインスタンスに適用されるIAMロールとなります。 ECSでコンテナを配置するホストインスタンスがEC2を利用している時にECSクラスターへ参加を行う際に必要となるIAMロールで、もしecs.configのような設定ファイルを配置する際にはS3へのアクセス権限をこちらのIAMロールに付与することで対応が可能かと思います。 このIAMロールに適用されるIAMポリシーとしてAmazonEC2ContainerServiceforEC2Roleは最低限必要になります。 ポリシーより、ECSでホストインスタンス情報を取得するために使用される権限がポリシーとして付与されております。 ecs:CreateCluster ecs:DeregisterContainerInstance ecs:DiscoverPollEndpoint e
GitHub Actionsで利用するIAMロールの信頼関係には、Conditionとして "token.actions.githubusercontent.com:sub" で組織とリポジトリとジョブ環境名を指定する必要があります。 コンサル部のとばち(@toda_kk)です。 先月、GitHub ActionsがOpenID Connect(OIDC)に対応したことが発表されました。 実はそれ以前から対応は進んでおり、公式なアナウンスはないものの、ちらほらと「試してみた」系の記事が上がっていました。 具体的には、AWS IAMのIDプロバイダーを利用することで、GitHub ActionsにAWSユーザーにアクセスキーなど永続的なクレデンシャルを渡すことなく、IAMロールをベースとした権限管理によってAWSリソースの操作ができるようになる、という内容です。 2021年現在、GitHub
スイッチロール先の本番・開発アカウントにてIAMロール、ポリシー、パーミッションバウンダリーを作ってみた AWS IAM の機能の中でも割とマイナーなPermissions Boundary(パーミッションバウンダリー)。今回はこれを活用してみました。 ちゃだいん(@chazuke4649)です。 今日はスイッチロールを前提とした本番・開発アカウント用のIAMロール・ポリシー・パーミッションバウンダリーを考えてみたのでご紹介します。 今回ブログの発展版もありますので、よければ以下続編ブログもご覧ください。 どういうこと? 構成図 解説 AWS環境の中に複数の環境を持つ場合、複数のアカウントに分けて運用することで一定のメリットを享受することができます。詳しくはこちらをご覧ください。今回は上図の様に、中央管理用のAWSアカウントにIAMユーザーを一元管理し、実際に構築・開発・運用する環境はAW
[アップデート] IAMロールセッション名にユーザー名を強制できる条件 sts:RoleSessionName が使えるようになりました ちゃだいん(@chazuke4649)です。 IAMロールの信頼ポリシーにて、新たに Conditon key として sts:RoleSessionName を設定できるようになりました。 IAM ロールを使用して実行されたアクションを担当する ID を簡単に特定 それによって、 例えばIAMロールを使用するクロスアカウント元のIAMユーザーに対し、ロールセッション名にIAMユーザー名の使用を強制することができます。 今まで「CloudTrailでアクションの実行者調べようと思ったら、クロスアカウントのユーザー名が任意のロールセッション名で誰か判別つかなくて困るよ〜」って経験がある人は大喜びだと思います。 何が嬉しいの?(詳しく) まず、登場する2つの
はじめに レプリケーションの設定をしている時に、IAMロール・AWSサービスロールという2つが出てきてそれぞれのロールの違いって何?となったので色々調べて自分なりに理解したのでそれを備忘録として残す IAMロール(単に「ロール」)とは 公式の説明の通り、IAMロール(単に「ロール」)とは、一時的な権限としてユーザとかサービスに権限を付与するのに使うもの このロールは同一AWSアカウント内のユーザの権限を制御するためにあるものではなく、 AWSのサービスに対して権限を付与する 他のAWSアカウントのユーザに一時的に使ってもらうための権限を付与する WebサービスからAWSのアクセスしたりするための権限を付与する という事をするために存在する そのため、AWSアカウントに属するユーザに対して権限を制御をするのにロールをアタッチして・・・という事は行わない (AWSアカウントに属するユーザに対す
EC2インスタンスプロファイルがSSM機能をDENYしていてもSSM Default Host Management ConfigurationのIAMロールにフォールバックします 2023年の2月にSSM Default Host Management Configuration(SSM DHMC)という機能がリリースされ、これまでEC2のインスタンスプロファイルでのみ設定可能だったSSM権限をSSMでもデフォルトとして設定可能になりました。 本機能発表時のしばたのブログ解説にもあるように、SSMのデフォルトロールは、EC2インスタンスプロファイルのフォールバックとして機能します。 このフォールバックは インスタンスプロファイルが設定されていない インスタンスプロファイルでSSM系の権限がALLOWされていない といったケースだけでなく インスタンスプロファイルでSSM系の機能がDENY
AWS Organizationsの登場などにより、AWSを使ったシステムでは複数のAWS アカウントをつかったマルチアカウント運用が増えています。 マルチアカウント運用ではIAMロールによるユーザの集中管理などが重要となってきます。 この記事ではこの集中管理の時の思わぬ注意点をご紹介します。 AWSにおけるマルチアカウントのベストプラクティス AWSのマルチアカウント運用を行う場合複数のパターンが考えられます。 各アカウントにIAMユーザを作成して個別にログインする。 IAM管理用の踏み台アカウントを作成し、各アカウントにはIAMロールを作成しスイッチロールを利用する。 AWS SSO を利用し、SSOログインを行う。 OneLoginのようなサードパーティーの認証プロバイダを利用する。 各アカウントを利用する方式は、メンバー変更があった際に、全てのAWSアカウントでユーザの追加、削除を
メンバーやサービスアカウントの権限を考える際に、ロールの持つ権限を比較したいことがしばしばある。そういう時は gcloud と diff を使うことで比較できるという素朴なテク。 ロールと権限 ロール(role)は roles/{roleName}, roles/{service}.{roleName} などで表され、許可されている操作を表す権限(permission)の集合である。 例えば BigQuery データ閲覧者 (roles/bigquery.dataViewer) は、以下の permission を持つ。 bigquery.datasets.get bigquery.datasets.getIamPolicy bigquery.models.export bigquery.models.getData bigquery.models.getMetadata bigquery
(※)2022年6月30以降に「暗黙的な自己信頼」の使用実績があるロールでは、2023年2月15日まで「許可」 個人的にちょっと勘違いしていたのは#4,#16のケースで、「同一アカウント」かつ「ユーザー/ロール単位で信頼している」場合にはプリンシパル側の IAM ポリシーでの許可はいらない、という点でした。 ちょっと試してみた 上記のパターンからいくつかピックアップして試してみます。 同一アカウントで信頼ポリシーだけで許可されているパターン #4,#5に該当するパターンです。 IAMUser0 に IAM ポリシーがアタッチされていない状態で、IAMRoleA を Assume Role します。 まずは IAMRoleA の信頼ポリシーが以下の場合です。(#4) IAMRoleAの信頼ポリシー { "Version": "2012-10-17", "Statement": [ { "Ef
みなさんどうも、新卒エンジニアのたいがーです? 何が起こったのかと言いますと、タイトル通りです。AWS CLIでインスタンスプロファイルとAWS Systems Manager(以下、SSM)の設定をしようとして、とても詰まりました。 私が"どういうところにハマったか、どう解決したか"、実際の流れに沿って書いていきたいと思います。 そもそも何があったのか 始めは、AWS CLIを使ってCloud Formationのテンプレートからスタックを作成しようとしていました。 今回のテンプレートでは、スタック実行前にインスタンスプロファイルを作成する必要があったため、IAMロールを新たに作成しなければなりません。全てAWS CLIを使って済ませたかった私は、コマンドリファレンスの中からIAMロールを作成するコマンドを見つけ、実行しようとします。 しかし、このコマンドでは、assume role p
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く