【AWS IAM Identity Center】ユーザー管理でよく使いそうな作成/削除系操作をAWS CLIでやってみる | DevelopersIO
【AWS IAM Identity Center】ユーザー管理でよく使いそうな作成/削除系操作をAWS CLIでやってみる 「ユーザー作成/削除」または「ユーザー棚卸し」といった IAM Identity Center の日々の運用作業は、 マルチアカウント環境がスケールするにつれて増えてくると思います。 だんだんマネジメントコンソールで作業することが辛くなってくるのでは無いでしょうか。 そんな運用の辛さを軽減するために、ぜひAPIは活用していきたいです。 以下アップデートから、 AWS IAM Identity Center (旧 AWS Single-Sign On) の IDストアに対してAPIから参照・更新ができるようになっています。 2022/08/31 - AWS SSO Identity Store - 15 new 4 updated api methods 本ブログではユ
こんばんわ、札幌のヨシエです。 今回は以前に書いたECSで利用するIAMロールのFargate版をまとめてみました。 結果を先に書くとEC2よりも検討するロールは少なくなりました、詳細なところはEC2に書いているので以下のURLを参照いただければと思います。 ECS(EC2)で利用するIAMロールを整理する どういうIAMロールが存在するのか？ EC2と同様に列挙してみました。 ロール名 役割 備考
Scaling AWS Lambda permissions with Attribute-Based Access Control (ABAC) | Amazon Web Services
AWS Compute Blog Scaling AWS Lambda permissions with Attribute-Based Access Control (ABAC) This blog post is written by Chris McPeek, Principal Solutions Architect. AWS Lambda now supports attribute-based access control (ABAC), allowing you to control access to Lambda functions within AWS Identity and Access Management (IAM) using tags. With ABAC, you can scale an access control strategy by settin
関西オープンフォーラム内で開催された"jus研究会大阪大会「AWS IAM - 設計上の戦略と戦術」"での発表資料です。 https://k-of.jp/backend/session/1299 運用設計ラボおよびJAWS-UG CLI専門支部での実践を例に、AWS IAM設計上の戦略と戦術について整理してみました。 (現在も、試行錯誤の途中であり、今後内容が改訂される可能性があります。) (運用設計ラボ合同会社 波田野裕一)
躓きまくったので備忘録。 AWS はこっち。 概要 GitHub Actions では OpenID Connect (OIDC) がサポートされています。 OIDC を使用することによりサービスアカウントキーなどを用意することなく Google Cloud に対する認証を行うことができます。 詳細については下記ページをご参照ください。 この記事では GitHub Actions で OIDC を使用して Google Cloud へ認証を行うまでの手順をまとめます。 リポジトリ この記事内で使用しているサンプルコードは下記リポジトリで管理しています。 手順 1. IAM Service Account Credentials API を有効にする OIDC で認証情報を作成するときには IAM Service Account Credentials API を利用するため、有効にしておく
【AWS IAM】Condition の条件キーやポリシー変数は可用性を意識しよう！という話 | DevelopersIO
突然ですが問題です あなたはAWS環境の管理者です。 IAMロールに付与したタグベース で、 EC2インスタンス開始/停止を制御しようと試みています。 現状 利用者ロールに割り当てている権限は PowerUserAccess 相当です。 以下のポリシーを追加で付与して制御を実現しました。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": ["ec2:StartInstances", "ec2:StopInstances"], "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "StringNotEquals": { "aws:PrincipalTag/Project": "${aws:ResourceTag/Project}" }}}
こんにちは、上野です。 Infrastructure as Code (IaC) 、みなさん楽しんでおりますでしょうか。前から気になっていたcdk-nagを試してみたので、その紹介となります。 cdk-nagとは AWS Cloud Development Kit (AWS CDK) で作成する各Constructが、与えられたセキュリティ・コンプライアンスルール群に準拠しているかどうか検証してくれるツールです。CloudFormationテンプレートのセキュリティチェックツールである、cfn-nagに影響を受け作成されています。現時点では以下のルール群が提供されています。 AWS Solutions HIPAA Security NIST 800-53 rev 4 NIST 800-53 rev 5 PCI DSS 3.2.1 GitHubリポジトリで公開されており、AWS公式ブログでも
Motivation AWSの現状を楽に構成図に落とせたらいいよね、というモチベーション。 たまたま、CloudFormationのコードから draw.io で構成図を書く cfn-diagram というツールを見つけたので、aws -> cfn ->draw.io の流れができないか試してみる。
AWSのIAMポリシーには、ジョブ機能あるいは職務機能と呼ばれるAWS管理ポリシーがあります。その中の1つであるネットワーク管理者から垣間見れるAWSの歴史についての小ネタです こんにちは、ゲストブロガーの佐々木拓郎（@dkfj）です。ひょんなことからDevelopers.IOに投稿させて頂けることになりました。普段は、SIerに勤務する傍らAWS本の執筆や技術同人誌を書いています。今日は、小ネタにAWSの歴史を絡めて、職務機能のAWS管理ポリシーを紹介したいと思います。 目次 目次 IAMポリシーでジョブ機能（職務機能のAWS管理ポリシー） 職務機能のユースケースもといAWS管理ポリシーの制限 NetworkAdministratorから読み解くAWSの歴史 明かされる真実 IAMポリシーでジョブ機能（職務機能のAWS管理ポリシー） IAMポリシーの選択時にフィルターのポリシータイプに出
はじめに S3へのアクセスを制御するために様々な機能がありますが、これらはIAMのアクセス制御と混同して考えられることが多く、両方の機能の関連について、質問を非常に多く受けています。 以前に S3のアクセス制御はまずシンプルに捉えて対応すべき という記事を書きましたが、この記事に書いたように、S3バケットポリシーとIAMポリシーには以下のような違いがあります。 S3バケットポリシーは、S3側で、エンティティから行われるアクセスの制御 IAMポリシーの場合、エンティティ側で、S3に対して行うアクセスの制御 このように、両者では設定箇所および制御する操作の矢印の方向が異なります。 基本はこの2つでS3バケットやオブジェクトに対するアクセス制御を行いますが、この2つに加えて、全く異なるアクセス制御の要素が加わることがあります。 その代表例と言える 「Presigned URL」 を今回は取り上げ
最低限のガードレールを考慮したシンプルな IAM 設計を CloudFormation でデプロイする | DevelopersIO
IAM 設計において、かんたんなガードレールや誤操作防止を考慮し、IAM リソースを１つずつ CloudFormation で構築する機会があったのでご紹介します。 ちゃだいん（@chazuke4649）です。 IAM 設計において、かんたんなガードレールや誤操作防止を考慮し、IAM リソースを１つずつ CloudFormation で構築する機会があったのでご紹介します。 前回ブログの発展版となりますので、よければ以下前回ブログもご覧ください。 「ガードレール」という概念については、以下記事を眺めてもらえれば掴めてくるかと思います。 AWS Security Roadshow Tokyo 2019午前セッションレポート | Developers.IO [レポート] アクセス管理の信頼性 (Access Control Confidence) #SEC316 #reinvent | Dev
「AWS IAMだけでなんとかする、 最低限のガードレール」というタイトルで #AKIBAAWS で登壇しました | DevelopersIO
ちゃだいん（@chazuke4649）です。 先日 【8/17（火）リモート開催】AKIBA.AWS ONLINE #06 – AWS IAM 編- にて、AWS IAMについて登壇しました。その際のスライド資料や動画を共有します。 スライド資料 動画 ※アップロードが完了次第更新します 補足情報 基本的に今回の発表は以下ブログを元ネタとし、一部抜粋して紹介しています。合わせてこちらのブログもどうぞ。
IAM Identity Centerを使って複数アカウント管理する。（その１：IAM Identity Centerでのログイン） - Qiita
IAM Identity Centerを使って複数アカウント管理する。（その１：IAM Identity Centerでのログイン）AWSSSOaws-ssoIAM_Identity_Center はじめに 仕事で初めてIAM Identity Centerを使う機会があり、使ってみたらマルチアカウントの管理が想像以上にやりやすかったので、紹介しようと思います。 【次】IAM Identity Centerを使って複数アカウント管理する。（その２：CLIでのアクセスと管理の委任） IAM Identity Centerとは AWS Single Sign-onの後継サービスとなり、AWS Organizationsで複数アカウントを運用している環境で各ユーザを集約管理し、各アカウントへのログインを簡単に行えるようにするためのサービスです。 前提として、AWS Organizationsを使
こんにちは、森田です。 研修中に、各部署でスイッチロールを付与してもらっていますが、そもそもスイッチロールとは何者なのかを理解していなかったので、実際に色々試しながら理解してみます。 スイッチロールとは IAMの機能の1つで名前の通り、アカウント切り替え用のロール（役割）を提供します。 例えば、下図の場合です。 会社などに属している場合、部署やサービスごとでアカウントを分けることがあります。 この時、スイッチロールを使用せず、コンソールにログインする場合、アカウント ID、ユーザ名、パスワードがそれぞれで必要となります。 上図の場合アカウントが3つなので、何とかなりそうですが、 例えば、より多くのアカウントを切り替える場合はその分管理する情報も増えてしまうため、とても大変になってしまいます。 そこでスイッチロールでは、アカウントを切り替えるために任意のアカウントに対して、一時的な権限を発行
なぜ書いたか やりたいこと tl;dr 特定サービス（の全リソース）に対する権限を付与したい 特定サービスの特定リソースに対しての権限を付与したい まとめ おまけ google_service_account_iam_member がややこしい なぜ *_iam_member を使うのか 参考 なぜ書いたか Terraform Google Provider のIAM周りのリソースはたくさんある。 google_project_iam_policy google_project_iam_binding google_project_iam_member google_service_account_iam_policy google_service_account_iam_binding google_service_account_iam_member google_cloud_run_
AWS CLIからCloudFormation でユーザとロールを作成して、流れるようにスイッチロールの確認をしてみた | DevelopersIO
AWS CLIからCloudFormation でユーザとロールを作成して、流れるようにスイッチロールの確認をしてみた 最近は、ABACばっかりやってるAWS 事業本部 梶原＠福岡オフィスです。 ABAC(属性ベースのアクセスコントロール ）を実施する際、ポリシーは同一にして、スケールすることができるのですが、ユーザやロールの確認作業は必要になってきます。 とはいえ、様々な属性値のユーザの確認作業を手作業でやるのは結構大変です。 ということで検証作業を楽にするため、ユーザー作成、ロール作成部分をTemplate化しました。必要に応じて修正（タグ値を追加など）して、ご自由にお使いください また流れで、ロールの検証を行いたいため、スイッチロールを楽にするために認証情報を取得しやすくしています。 credentialsの設定や、configの設定って微妙にはまりがちなのでなるべく簡単に定型作業で
IAM Access Analyzer を利用して、アクセスアクティビティに基づいて IAM ポリシーを生成し、最小限の権限のアクセス許可を簡単に実装する | Amazon Web Services
Amazon Web Services ブログ IAM Access Analyzer を利用して、アクセスアクティビティに基づいて IAM ポリシーを生成し、最小限の権限のアクセス許可を簡単に実装する 2019 年に AWS Identity and Access Management (IAM) Access Analyzer がリリースされ、既存のアクセス許可の設定状況を分析することで、意図しないパブリックおよびクロスアカウントアクセスを削除できるようになりました。2021 年 3 月、IAM Access Analyzer は、ポリシーの作成中にセキュリティで機能的なアクセス許可を設定するのに役立つポリシー検証機能を追加しました。そして、IAM Access Analyzer はさらに一歩進み、ポリシーを生成します。IAM Access Analyzer を使用して、AWS Clo
サービスアカウントで BigQuery にアクセスするときに、どのロールでどんな操作が可能なのか確認してみた。 | DevelopersIO
サービスアカウントで BigQuery にアクセスするときに、どのロールでどんな操作が可能なのか確認してみた。 こんにちは、みかみです。 やりたいこと BigQuery の事前定義ロールにはどんな種類があるか知りたい 各ロールでどんな操作ができるのか知りたい BigQuery Python クライアントライブラリを使用する場合に、各ロールで実行可能な処理を確認したい 目次 GCP の権限管理 BigQuery の事前定義ロールを付与したサービスアカウントを作成 Python クライアントライブラリ経由で BigQuery を操作 プロジェクト関連操作 データセット関連操作 テーブル関連操作 テーブルデータ関連操作 ルーティン関連操作 モデル関連操作 ジョブ関連操作 許可されていない操作を実行した場合の挙動 ロールごとに実行可能な操作一覧 まとめ（所感） 参考 GCP の権限管理 GCE や
AWS でパスワードなどの秘密情報をコードに埋め込まずに利用する方法 | クラウド・AWSのIT技術者向けブログ SKYARCH BROADCASTING
某所で API キーを含む秘密情報をコードに含めて一般公開した為に不正アクセスの原因になった可能性があると話題になっています。 AWS でもサービス利用は基本的には全て REST API を通じて行われため、コードに対して何らかの形でAPIキーとシークレットを渡す必要があります。その為やはり類似の事故が発生する可能性は常にあり、定期的な注意喚起が行われています。 AWS では責任共有モデル1 が採用されており、当たり前のことですがデータの保全処置やパスワードの管理はユーザの責任となります。 そもそもコード中にAPIキーなどの秘密情報を埋め込まなくても安全に利用する仕組みが提供されています。 今回はそのうちのいくつかをご紹介したいと思います。 IAM ユーザ AWS リソースへのアクセスを制御する最も基本的な機能です。IAM ユーザという単位で ID、パスワードを発行し、マネジメントコンソー
【初心者向け】Session Manager でインスタンスが表示されない時のトラブルシュート | DevelopersIO
ちゃだいん（@chazuke4649）です。 Session Manager の初期設定って、よくつまりませんか？ 私はよくつまります。 今日は先日久しぶりにさわったところ、やはりつまったので、次つまった時のためにメモを残しておこうと思います。そして、Well-Architected Flameworkにならい、質問形式で未来の自分へチェックすべきポイントを投げかけてみます。 参考URL 1. EC2インスタンス / エージェントが原因 いくつかのカテゴリに分けてみました。最初は、EC2インスタンス周りや、その中に起動している SSM エージェントに関してです。 IAMロールが不適切ではありませんか？ 基本的には、対象のEC2インスタンスにアタッチされているIAMロールに、IAMポリシーのマネージドポリシーであるAmazonSSMManagedInstanceCoreがアタッチされていれば
(初心者向け) AWSのアカウントを守るために最低限やっておきたいことまとめ ( IAMメイン ) - Qiita
はじめに これまで業務でAWSを触る機会もあったのですが、1からアカウントを運用するなどは経験がなく基本的な部分が抜けているなと感じたので、自身の知識の確認も含めて、AWSアカウントを安全に利用するためのセキュリティの基礎中の基礎をまとめてみました。 対象読者 AWSアカウントを開設してばかりの方 AWS IAMの設定内容に自信がない方 IAM ベストプラクティスで推奨されている内容をさくっと確認したい方 AWSにおけるセキュリティの考え方 AWSはさまざまな便利なサービスをクラウドサービスとして提供してくれていますが、クラウドサービスだからといってセキュリティのあらゆる部分をAWSが担保してくれるわけではありません。 セキュリティに関してAWSがどの範囲は責任を持ってくれるのか、また利用者側がどの範囲のセキュリティを検討しなくてはいけないのかは「責任共有モデル」という形で明示されています
概要 AWS IAM Identity Center 昔はAWS SSOと呼ばれていたました これを使うことで、複数AWSアカウントのIAMを統一的に管理することができます 複数アカウントのIAM管理手法はいくつかあります スイッチロールによる管理との比較、メリットについては 株式会社PLAN-Bさんがまとめてくれています 下記記事がとても分かりやすいと思います IAM Identity Centerは既存のIAMユーザーと競合しないので、段階的に一部のユーザーだけ試してみるといった運用も可能です 同じユーザー名でも問題ありません 今回は以下のようにaccountA、accountBに存在するyamasitaアカウントをIAM Identity Centerのyamasitaに移行するまでの設定をやってみます 以下のようにログインのURLが変わりますが、ログイン後の使用感は変わりません 実
IAM で MFA デバイスを複数登録が可能となった影響で MFA 強制の IAM ポリシーに修正が必要です - サーバーワークスエンジニアブログ
カスタマーサクセス部 佐竹です。 本日は、以下のアップデートに関する運用上の注意点のお知らせです。IAM ポリシーで、IAM User に MFA デバイスの設定を強制されている場合に、本アップデートによる影響がありましたので周知のために記載しております。 aws.amazon.com はじめに アップデートの影響 IAM ポリシーへの影響 修正が必要な個所 ${aws:username} 発生するエラー 修正後の IAM ポリシー json 注意点やその他のご連絡事項 影響を受けないお客様 まだ全ての AWS アカウントが複数の MFA デバイス登録に対応していない 2台目の MFA デバイス登録からエラーが発生する場合 1台目の MFA デバイス登録からエラーが発生する場合 MFA デバイス名は AWS アカウント内で一意でなければならない 修正後はアスタリスク (*) で問題はないの
AWSとAzureのID管理の違い【AWS技術者のためのAzure入門 第１回】 | エディフィストの実務に活かせるIT研修 | エディフィストの実務に活かせるIT研修
「AWS はわかるのだけど、Azure がよくわからない」といった方に、AWS（Amazon Web Services）と Microsoft Azure を比較しながら、考え方や概念の違いを解説します。 マルチクラウド化の流れが進む中、エンジニアの側も一つのクラウドシステムに執着するのではなく、複数のクラウドシステムを使いこなす必要がでてきています。しかしながら、同じ機能を実装するケースでも、クラウド間で手順や考え方が異なることから戸惑う方も多いのではないでしょうか。 本連載では、技術者のマルチクラウド化で最も多いと思われる、AWS に慣れ親しんだ方が Azure を覚えようとするケースで、躓きがちなポイントにフォーカスして解説します。 連載１回目では、AWS と Azure の ID 管理の違いについて見ていきます。 ※ Amazon Web Services、『Powered by
今すぐやめようssh! AWS Session Managerを検証・導入してみた - asoview! Tech Blog
この記事は アソビュー！ Advent Calendar 2019 - Qiita 17日目の記事です。 アソビューにてバックエンドおよびSREを担当している寺岡（@toda_kk）と申します。よろしくお願いします！ 最近はリングフィットアドベンチャーをやり始め、スクワットをする度に「いいぞ！」「すごいぞ！」と褒められることで自己肯定感を高めています。 はじめに さて、SREの業務というと、どの企業でも多岐にわたるかと思います。インフラアーキテクチャの設計および構築、モニタリング環境の整備、開発フローや運用業務の効率化……などなど、ビジネス上あまり目立たないけれど実は大事な役割を担っていたりします*1。 そんな中で、今回は開発や運用の効率化のためにAWSのSession Managerという機能を検証・導入した話を取り上げたいと思います。 Session Managerとは？ AWS Sy
イラストで理解するIAMロール
はじめに 先日、AWSのアクセス制御についてのプレゼンを行いました。 その際、ポリシーが増える場合、どのように対応すれば良いですか？という質問を頂きました。 そこで、ポリシーを管理するためのIAMロールの説明がうまくできませんでした。 ポリシーやロールは普段から触ることも多いですが、そのメリットをちゃん理解できていなかったことを自覚しました。 そこで、AWSのIAMロール周りのことを聞かれて「ドキッ」とする、そんな私のような方は是非読んでみて下さい。 概要 この記事ではIAMロールの利点に焦点を当てているので、あまり細かい仕組みの説明はしておりませんので、あしからず。 ポリシー ポリシーってなに？ そもそも、ポリシーってなんでしょう？ ポリシーがあって何がいいんでしょう？ では、まずポリシーがない状況を考えましょう。 ポリシー(権限)が無いと、誰でも、いつでも、なんでも、操作できるという状
Amazon Web Services ブログ SaaSテナント分離をAWS IAMとABACで実装する方法 この記事は、How to implement SaaS tenant isolation with ABAC and AWS IAMを訳したものです。 マルチテナントアプリケーションにおいては各テナントのリソースが他のテナントからアクセスできないように設計を行う必要があります。AWS Identity and Access Management (IAM) は多くの場合、この目的を達成するための重要な要素となりえます。一方で、IAMを用いることによる課題の一つとして、テナント分離を実現するのに必要な IAM ポリシーの数と複雑さが急速に拡大することにより分離モデルの規模と管理性に影響を与えることが挙げられます。IAM の 属性ベースのアクセスコントロール (ABAC) の仕組みはこ
背景 IAMはアクセス制御をする上で非常に重要な仕組みですが、一方で複雑になりがちです。 間違った理解のままだと必要以上の権限を与えてしまい、事故の原因となるので押さえておくべき点をいくつかまとめてみます。 リソース階層 GCPのIAMにはリソース階層があり、それぞれの階層を意識した上でIAMポリシーを設定する必要があります。 ref: リソース階層を使用したアクセス制御 | IAM のドキュメント | Google Cloud リソース階層は４つのレベルがあります。 組織レベル フォルダレベル プロジェクトレベル リソースレベル（一部のサービスのみ） IAMポリシーは階層構造になっていて、最終的にリソースで有効なポリシーは、そのリソースに設定されたポリシーとその上位レベルから継承されたポリシーの和となります。 このような考え方はReBAC(Relationship-Based A
IAMのベストプラクティス！rootユーザのアクセスキーはできるだけ削除していきましょう | DevelopersIO
みなさん！rootユーザのアクセスキー、使ってませんか？ AWSのユーザのアクセスキー/シークレットキー(以下、アクセスキー)が漏洩すると、その所持する権限に応じて様々な被害が生じます。 参考： 【実録】アクセスキー流出、攻撃者のとった行動とその対策 | Developers.IO 中でもrootユーザは何でもできる最強の権限を持つため 万一そのアクセスキーが悪意ある者の手に渡ってしまうと、 AWSアカウントのrootメールアドレス変更 root含む全ユーザのログインパスワード変更 大事なシステムが稼働しているAWSアカウント解約 マイニングなど、リソースの不正利用によるクラウド破産 S3に保存した機密情報流出 などなど、とっても恐ろしいことが起こってしまいます。（※下2つはroot権限でなくとも起こりえます） 弊社にも、まれにrootユーザのアクセスキー漏洩事故、およびそれに伴うAWSア
Looker Studio（旧データポータル）からBigQueryなどのデータソースに接続する場合の認証について主に次の3種類に区分されます。 オーナーの認証情報 閲覧者の認証情報 サービスアカウント 1はLooker Studioでレポートを作成したオーナーの認証情報をつかったアクセスです。2はレポートを閲覧したユーザーアカウントの認証情報をつかったアクセスです。3はユーザーではなく、共通のアカウントとなるサービスアカウントによるアクセスです。 ユーザーアカウントによる認証情報ではなく、サービスアカウントを利用することのメリットは以下のとおりです。 （オーナーの認証情報を使用している場合）退職やアカウント停止による影響をうけない （閲覧者の認証情報を使用している場合）閲覧者一人ひとりに対してアクセス権限を付与する必要がない Looker Studioからサービスアカウントを使用する方法に
はじめに こんにちは。大阪オフィスの林です。 タイトルの通りなのですが本エントリは、AWS環境で各種リソースやサービスに対する管理者権限を与えつつも、IAMユーザーの作成や変更に関する操作を禁じたいというピンポイントのユースケースにお答えする内容となっています。 デフォルトのポリシーでIAMReadOnlyAccessもありますが、ロールやポリシーの操作にも制限が掛かってしまうので、IAMユーザーの作成、変更に対する操作だけを禁止したいというユースケースに本エントリを参考にして頂ければと思います。 やってみた ポリシー作成 IAMのダッシュボード左メニューから「ポリシー」-「ポリシーの作成」を選択します。 「JSON」タブから下記のJOSNをコピペして次のステップに進みます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Al
IAMインスタンスプロファイルって？
概要 AWSリソースにIAMポリシー権限を渡すときはIAMポリシーがアタッチされているIAMロールを作成し、そのIAMロールをAWSリソースに付与することで付与されたAWSリソースは他のリソースへの操作権限が与えられます。 ですがEC2を作成する画面にIAMロールをアタッチする箇所がなく、IAMインスタンスプロファイルを設定する箇所が存在します。 AWS CLIでもパラメータにIamInstanceProfileという項目があり、Arnにもinstance-profileと記載されています。 aws ec2 describe-instances --query "Reservations[].Instances[].IamInstanceProfile.Arn" [ "arn:aws:iam::XXXXXXXXXXXX:instance-profile/Yuta20210911" ] この
Optimize your Google Cloud environment with new AI-based recommenders | Google Cloud Blog
Optimize your Google Cloud environment with new AI-based recommenders You want your Google Cloud environment to be as unique as your organization, configured for optimal security, cost and efficiency. We are excited to offer new recommenders for Google Cloud Platform (GCP) in beta, which automatically suggest ways to make your cloud deployment more secure and cost-effective, with maximum performan
【GCP】Cloud IAMの概念を整理してみた
はじめに IAMを触る時、「ロールとポリシーの関係ってなんだっけ？」、「サービスアカウントってなんだっけ？」と毎回調べて雰囲気のまま使っていました。 今回は、再度勉強しなおしてCloud IAMについて纏めてみました。 Cloud IAMとは Cloud IAMとは「誰（ID）」が「どのリソースに対して」「どのようなアクセス権（ロール）」を持つかを定義することにより、アクセス制御を管理できます。 例えば、下記のようなこと設定をすることがで、適切なアクセル管理をすることが可能です。 「開発者A」に「Cloud FunctionsとPub Sub」の「閲覧と編集」を行える 「Cloud Functionsの関数A」は「Cloud Strage」の「作成」のみを行える Cloud IAMの概念 公式ドキュメンに正しく詳細な説明があるので、こちらも参照いただければです。 ここでは自分が理解したもの
コーヒーが好きな木谷映見です。 今日はスイッチロールの概念と設定方法についてまとめていきます。 スイッチロールとは？ ざっくりとしたイメージ 真面目なイメージ スイッチロールのイメージ 「帽子をかぶって力を得る」 IAM ポリシーの種類 アイデンティティベースのポリシー リソースベースのポリシー IAM ロールの信頼ポリシー sts:AssumeRole とは IAM ロールに付与されるポリシー スイッチロールをする際の権限まとめ スイッチロールの手順 スイッチ元アカウントA での準備① スイッチ先アカウントB での準備 スイッチ元アカウントA での準備② スイッチ元アカウントAからスイッチ先アカウントへスイッチロールする スイッチロールのユースケース 参考 具体的な設定方法を知りたい方は「スイッチロールの手順」をご参照ください。 スイッチロールとは？ ざっくりとしたイメージ 「人んちの帽
SREチームの橋本です。SRE連載の11月号になります。 AWSの多くのリソースはIAMでアクセスを一元管理されていますが、Lambdaではユーザーが実行したり他のAWSサービスから実行されたりする都合上、様々なポリシーが絡んでいます。 特に「Lambdaを呼び出す許可」についてはID（アイデンティティ）ベースのポリシーとリソースベースのポリシーで内容が被るため、どちらで設定するか混乱しているケースも見られます。 本記事ではこうしたポリシー事情をterraformの例と共に整理し、権限設定のベストプラクティスも検討します。 そもそもIAMのポリシーについて ドキュメントによればAWSのポリシーは実に6種類ものタイプがありますが、「使用頻度の高いものから」とあるように最初のIDベースが非常に多くのサービスで共通して使われており、次いで2番目のリソースベースが一部サービスで必要になるでしょう。
G-gen の杉村です。Google Cloud (旧称 GCP) には組織 (Organization) という概念があります。ガバナンスとセキュリティのために重要なこの機能を解説します。 組織の基本 組織 (Organization) とは リソースの階層構造 組織リソース 組織 ID（顧客 ID） フォルダ・プロジェクト 組織のメリット・ユースケース 組織を使う理由 複数プロジェクト管理 利用可能なサービス・機能 組織を使わないリスク 組織の作成 Google Workspace (Cloud Identity) と Google Cloud 組織の作成方法 組織作成直後の特権 組織の表示 階層構造 (ツリー) の表示 表示に必要な権限 組織の管理 組織の管理者ロール 強力な管理権限 管理の委任 監査 組織と Cloud Audit Logs 監査ログの収集 組織 (Resource
AWS Fargate サービスを Terraform で構築、 コマンドラインからデプロイ - Qiita
動機 【AWS】 Fargate CLI + Terraform で Docker コンテナを動かす簡単なチュートリアル というのを書いたんですが、下記の問題点を感じました。 Fargate CLI のインストールが若干手間。 Fargate CLI を使うと、 Terraform だけで完結しないため、一部ハードコーディングが必要になる。 Fargate CLI は冪等性が無い。 SSL 証明書や Route53 周りは Terraform で設定したいが、 Fargate CLI で設定した値の取得には結局 aws-cli を叩く必要がある。 Fargate CLI でも設定可能だが、事前に Route53 で設定とかしないとうまく動いてくれなかった記憶があり、結局あんま信頼できなかった よって、最近は Fargate CLI は使わずに、 インフラ構築は Terraform に全て任
スイッチロール先の本番・開発アカウントにてIAMロール、ポリシー、パーミッションバウンダリーを作ってみた | DevelopersIO
ちゃだいん（@chazuke4649）です。 今日はスイッチロールを前提とした本番・開発アカウント用のIAMロール・ポリシー・パーミッションバウンダリーを考えてみたのでご紹介します。 今回ブログの発展版もありますので、よければ以下続編ブログもご覧ください。 どういうこと？ 構成図 解説 AWS環境の中に複数の環境を持つ場合、複数のアカウントに分けて運用することで一定のメリットを享受することができます。詳しくはこちらをご覧ください。今回は上図の様に、中央管理用のAWSアカウントにIAMユーザーを一元管理し、実際に構築・開発・運用する環境はAWSアカウントとして分けて作成し、その環境へは中央管理用のAWSアカウントからスイッチロールしてアクセスするというものです。 これによる最大のメリットは、管理すべきユーザーを一元的に集中管理できる様になるため、アカウント数の追加に伴ってユーザー数も増やさな
業務都合で GCP を使う機会が増えたけど、サービスアカウントってなんかわかりにくいなぁってずっと思ってた。でもそれは AWS の考え方を引きずっていたからだと気づいたので、両者の権限付与について違いをまとめる。ざっくりしたまとめなので、詳細な仕様は公式を参照。 権限そのものの考え方は大体同じ Policy: 権限そのもの。基本的にサービスごとのAPIに対する権限と考える。細かいことを書き出すときりがないので割愛。 Role: 権限をグループ化したもの。細か(略 PolicyやRoleの付与対象 違いは一番下。人以外に対する権限付与のアプローチが違う。 AWS IAM User IAM Group Resource GCP Google Account Google Group Service Account 違いは「何を抽象化したか」 AWS リソース(=プログラム)を人に見立てて権限を
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ECS(Fargate)で利用するIAMロールを整理する | DevelopersIO
AWS IAM 〜 設計上の戦略と戦術 / 20191109-kof-iam
GitHub Actions で OIDC を使用して Google Cloud へ認証を行う
cdk-nagを使用したAWS CDKのセキュリティチェック ～基本編～ - NRIネットコムBlog
aws -> cfn ->draw.io を試す
職務機能のAWS 管理ポリシーから昔を振り返る | DevelopersIO
Amazon S3 Presigned URLのアクセス制御を深堀りする - Qiita
スイッチロールをやってみた | DevelopersIO
Terraform で GCP のサービスアカウントを管理する - Eng (なりたい)
AWS IAM Identity CenterでIAMアカウントを統一する
SaaSテナント分離をAWS IAMとABACで実装する方法 | Amazon Web Services
GCPのIAMを使う上で理解しておくこと - Carpe Diem
サービスアカウントでLooker Studio（旧データポータル）からBigQueryに接続する
管理者権限を与えつつIAMユーザーまわりの操作だけ禁止するIAMポリシー | DevelopersIO
帽子をかぶって、スイッチロールをマスターしよう - サーバーワークスエンジニアブログ
AWS Lambda のアクセス許可を紐解く - KAYAC Engineers' Blog
Google Cloudの組織(Organization)を徹底解説 - G-gen Tech Blog
権限付与から見たAWSとGCPの違い - public note