こんにちは、上野です。 皆様、IAMユーザーのアクセスキー、どう管理されていますでしょうか？ AWSの操作をローカルPCや外部のサービスから利用できる便利な反面、一度外部に漏れるとそれが悪用されてしまうというリスクもあります。クラウド環境におけるインシデントの多くが、このアクセスキー（認証情報）に関するものになっています。 ということで、アクセスキーが作成されたらとりあえず気づけるように。という方法を紹介します。 アクセスキーとは？ 復習の意味も込めて。AWSにおけるアクセスキーとは。わかる方は飛ばしてください。 AWSにおいて認証を行う場合、基本的にはIAMユーザーを作成します。（AWS SSOを使うこともあります） IAMユーザー作成時、ID・パスワードの組み合わせ、またはアクセスキーID・シークレットアクセスキーの組み合わせを認証情報として使用できます。（ID・パスワードとアクセスキ
[新機能] AWS Security Token Service（STS）が東京リージョンで PrivateLink（Interface Endpoit）に対応しました | DevelopersIO
こんにちは、菊池です。 本日ご紹介のアップデートはこちらです。 AWS Security Token Service Now Supports AWS PrivateLink in US East (Virginia), US East (Ohio), EU (Ireland), Asia Pacific (Tokyo) AWS Security Token Service（STS）が、VPCエンドポイント（Interface Endpoint）に対応するリージョンが追加されました。これまでも、オレゴンリージョン（us-west-2）ではサポートされていましたが、追加で以下のリージョンで利用可能になっています。 バージニア（us-east-1） オハイオ（us-east-2） アイルランド（eu-west-1） 東京（ap-northeast-1） やってみた 早速、東京リージョンで試して
![[新機能] AWS Security Token Service（STS）が東京リージョンで PrivateLink（Interface Endpoit）に対応しました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/5ad4151a0f7cc53e37a5df16dda496ed03757a11/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Famazon-vpc-private-link.png)
この記事は terraform Advent Calendar 2019, エムスリー Advent Calendar 2019 の 3 日目の記事です。 All your AWS Accounts are belong to us. *1 こんにちは、ここ数年で terraform で書いた aws_vpc + google_compute_network の数がようやっと 30 個ぐらいになろうかというエンジニア/CTOの矢崎 id:saiya です。 弊社でまとまった規模の AWS 環境を扱う際に、1 つの terraform プロジェクトで複数の AWS アカウントに対してまとめて plan & apply できるようにしていたのですが、その方法が意外と調べにくい様子でしたので、まとめてみました。 なお、やり方が分かってしまえば実施するのは結構簡単です。 これによって出来ること 1
AssumeRoleで取得した一時クレデンシャルの情報を環境変数にセットしてもAWS認証が通らずハマった話 | DevelopersIO
こんにちは、CX事業本部の若槻です。 前回投稿した次の記事の執筆のための検証の際に、 AssumeRole（スイッチロール）で一時クレデンシャルを取得して環境変数にセットするワンライナー | Developers.IO 記事で紹介しているワンライナーにより取得した一時クレデンシャルの情報を環境変数にセットしてもAWS認証が通らずハマったので、その際の話を共有します。 事象 前述の記事で紹介している次のコマンドを実行して、AssumeRoleで取得した一時クレデンシャルの情報をを環境変数AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEYおよびAWS_SESSION_TOKENにセットしました。 % target_profile=<Assume先プロファイル名> % mfa_code=<6桁のMFAコード> % AWS_STS_CREDENTIALS=`aws st
EKSクラスターへ「kubectl」コマンドでアクセスする際の認証・認可の仕組みと設定 | DevelopersIO
上記のデフォルトロールに当てはまらないアクセス権限を定義したい場合は、新たなロールを定義することになります。 例えば、ポッドの参照のみ行えるアクセス権限は、以下のロールで定義できます。 pod-reader-clusterrole.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] $ kubectl apply -f pod-reader.yaml clusterrole.rbac.authorization.k8s.io/pod-reader created ただし、実際には「ポッドの参照のみ」のアクセス権
サンドボックス、開発、テスト環境で IAM ポリシー作成を一元化および自動化する方法 | Amazon Web Services
Amazon Web Services ブログ サンドボックス、開発、テスト環境で IAM ポリシー作成を一元化および自動化する方法 本番環境に対応したアーキテクチャに移行する際、お客様のアプリケーションチームはサンドボックス環境で AWS のサービスを試して、AWS の進化していくイノベーションに対応することができます。アプリケーションチームは、さまざまな AWS のサービスとリソースにタイムリーにアクセスする必要があります。つまり、最低限の権限を与えられることを保証するメカニズムを必要とします。通常、アプリケーションチームは、定期的に Amazon Elastic Block Store のスナップショットバックアップを行う AWS Lambda 関数や、セキュリティチームが管理する一元化された情報セキュリティアカウントにイベントを送信する Amazon CloudWatch Even
[速報] AWS Identity and Access Management Access Analyzerがリリースされました！ #reinvent | DevelopersIO
こんにちは。サービスグループの武田です。 現在re:Invent 2019に参加していますが、キーノートを前にして新機能のリリースが止まりません！今回新しく、AWS Identity and Access Management Access Analyzer（以下、IAM Access Analyzer）がリリースされましたのでお届けします。 Introducing AWS Identity and Access Management (IAM) Access Analyzer IAM Access Analyzerとは IAM Access Analyzerはサポートしているリソースが、意図したどおりのアクセスのみを提供しているかを継続的にチェックできるサービスです。リリース時点でサポートしているリソースは次のとおりです。 Amazon S3バケット AWS KMSキー Amazon S
![[速報] AWS Identity and Access Management Access Analyzerがリリースされました！ #reinvent | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/098a01a332248d791825217579652e1b7f202bcb/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F12%2Freinvent2019_update_eyecatch.jpg)
【レポート】＜認証の標準的な方法は分かった。では認可はどう管理するんだい？＞ – Developers.IO FUKUOKA/TOKYO 2019 #cmdevio | DevelopersIO
旬の生魚おじさん、都元です。11月ですよ！ Developers.IO イベントが今年もやってまいりましたよ。サンマもやってきていますよ！ もう召し上がりましたでしょうか？ 今年のサンマは高いですが…、強く生きようと思います。 さて、去る 10/26(土) 福岡にて、また 11/1(金) も東にて Developers.IO 2019 イベントを開催しました。これらのイベントで「認証の標準的な方法は分かった。では認可はどう管理するんだい？」と題しましてお話させていただきました。 本エントリーは、そのセッションレポートとなります。 スライド 個人的な話ですが、ここ数年の登壇では OpenID Connect の話をさせていただくことが多くなっております。そこでよくある質問として「認証についてはよく理解できました。では、認可って何かうまい仕組みで管理できないもんでしょうか？」というものがありま
GitHub ActionsにAWSクレデンシャルを直接設定したくないのでIAMロールを利用したい | DevelopersIO
こんにちは！コンサル部の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外のサービスに永続的なクレデンシャル
AWSのAPIへのリクエストではV4署名が必要です。Boto3でなく自分で直接HTTPリクエストを作る場合は署名も自分で行う必要があります。そのような時に使える方法をご紹介します。 AWSのAPIへのリクエストではV4署名による認証が必要です。 通常はAWS SDK(Pythonの場合はBoto3)が署名を行ってくれますので、ユーザは署名について意識する必要はありません。 しかし、AWSと同じ認証方式のAPIに対するHTTPリクエストを自分で生成する場合は、署名も自分で行う必要があります。 例えば以下のようなケースです。 IAM認証しているElasticsearch Serviceへリクエストするとき API Gatewayで作ったAPIにIAM認証をかけているとき 本記事では、このような場合に使える方法をいくつかご紹介します。 署名用パッケージを使う 簡単かつ確実なのは、署名用に作られた
![[Python] Boto3以外でV4署名リクエストを行う | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/47371cd63121a4cc67ed74841e706530c7e548f8/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F04%2Fpython.png)
AWS CLIで動かして学ぶCognito IDプールを利用したAWSの一時クレデンシャルキー発行 | DevelopersIO
「Cognito IDプールってやつはAWSリソースへのアクセスを制御する認可部分を担当しているらしいけど、いったいどういう理屈でそうなってるんだ…？」 そんな自分の疑問からAWSのドキュメントを読み実際に手を動かして得られたCognito IDプールに対する理解をまとめました。 「Cognito IDプールってやつはAWSリソースへのアクセスを制御する認可部分を担当しているらしいけど、いったいどういう理屈でそうなってるんだ…？」 そんな自分の疑問からAWSのドキュメントを読み手を動かして得られたCognito IDプールに対する理解を、 AWS CLIで再現できる形にまとめてみました。 Cognito IDプールでAWSの一時クレデンシャルキーを発行することによって、Cognito IDプールの世界からIAMの世界へ落とし込めると、だいぶイメージが付きやすいんじゃないかと思います。 AW
[AWS IoT] 既存の証明書だけでMQTT以外の各種AWSリソ−スにアクセスする (Authorizing Direct Calls) | DevelopersIO
[AWS IoT] 既存の証明書だけでMQTT以外の各種AWSリソ−スにアクセスする (Authorizing Direct Calls) AWS IoT の Authorizing Direct Callsを使用すると、既存の証明書だけで、AWSリソースにアクセスする事が可能です。 1 はじめに CX事業本部の平内（SIN）です。 AWS IoT のメッセージコアへのMQTTアクセスでは、通常、X.509 証明書が使用される場面が多いと思います。 しかし、例えば、「デバイスからMQTT以外に、S3への画像送信が必要」となった場合、ちょっと思いつくのは、以下のような感じでしょうか・・・ MQTTのペイロードに画像を押し込んで、ルールで処理する（MQTTのサイズ制限がちょっと不安） ユーザIDを発行してアクセスキーをデバイスに配置（ちょっと、美しくない？） CognitoのIdentity
![[AWS IoT] 既存の証明書だけでMQTT以外の各種AWSリソ−スにアクセスする (Authorizing Direct Calls) | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/d9fdf277e5e3da9b9ad5eb3751b2220bf7849aa7/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Faws-iot-core.png)
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": {
[AWS Organizations] SCP(サービスコントロールポリシー)の継承の仕組みを学ぼう | DevelopersIO
はじめに 大阪オフィスの川原です。 AWS Organizations の SCP(サービスコントロールポリシー)の継承 について、 仕組みを学びましょう。 前提知識 AWS Organizationsは マルチアカウントを統率するためのサービス です。 組織単位(OU) による アカウントのグループ化や、 サービスコントロールポリシー(SCP) によるグループ単位のサービス制限が可能です。 – 画像: AWS Organizations の用語と概念 | AWSドキュメント OUとは 組織単位(Organizational Unit: OU) は AWSアカウントのグループ化 を実現する要素です。 OU 配下に他OUをぶらさげる、ツリー構造を構築できます。 SCPとは サービスコントロールポリシー(SCP)は OUまたはアカウントに指定するポリシー です。 OU/アカウントで実行できるサ
![[AWS Organizations] SCP(サービスコントロールポリシー)の継承の仕組みを学ぼう | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/d2c2cbb34cdcda62e4504734b6e345b95ceca145/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F04%2Faws-organizations.png)
Temporary elevated access management with IAM Identity Center | Amazon Web Services
AWS Security Blog Temporary elevated access management with IAM Identity Center AWS recommends using automation where possible to keep people away from systems—yet not every action can be automated in practice, and some operations might require access by human users. Depending on their scope and potential impact, some human operations might require special treatment. One such treatment is temporar
はじめに Amplifyを利用してアプリケーションを作る場合、Cognito User Pool／Cognito Identity Pool（Cognito Federated Identities）を利用してAPI GatewayでAuthorizationする方法が暗黙裡にデフォルトになっているように見えます。 よく使われるであろうと思われる割には、その仕組みについての説明があまり見当たらなかったので解説記事を書こうとしましたが、前提となる事項があまりにも多いことが分かったので、個別の記事として分離しました。 本稿では、AccessKeyIdやSecretAccessKeyの使われ方、AWS APIにおけるSignature V4の仕組みなどについて解説します。 API GatewayのAuthorization方式として「AWS_IAM」という項目を選択できますが、本稿の内容を理解す
AssumeRole（スイッチロール）で一時クレデンシャルを取得して環境変数にセットするワンライナー | DevelopersIO
こんにちは、CX事業本部の若槻です。 今回は、AWS CLIでAssumeRole（スイッチロール）により一時クレデンシャルを取得して環境変数AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKENにセットしてAWS接続時の認証に利用可能とするワンライナーを作ってみたのでご紹介します。 前提 AWSプロファイルが次の通り設定済みであること。（Assume先プロファイルのmfa_serialは必要な場合のみ） ~/.aws/config [default] region=ap-northeast-1 output=json [profile <Assume先プロファイル名>] region = ap-northeast-1 mfa_serial = arn:aws:iam::xxxxxxxxxxxx:mfa/hoge role_arn
プラットフォーム技術部の小林正彦です。 本記事では「わかるようでよくわからないポリシー」のお話をしていきたいと思います。 AWSの公式ドキュメントにはポリシーに関する膨大な情報が掲載されています。しかしながらそれらの内容を机上で整理して理解するのは難しいです。「どういう場合にどのポリシーを定義するとよいのか」「それらを適用する上での注意点は何か」をつかめていないと、がんばって実装してみたのにメンテナンス困難なポリシー設計になってしまったなんてことになりかねません。 そういった事態に陥らないために「どういう場合にどのポリシーを定義するとよいのか」、「それらを適用する上での注意点は何か」を整理していきますが、すべてを解説しようとするととんでもない量になってしまうので本記事では「タイプの違い」に注目してポイントを記載していきます。 ポリシーの基礎的な話からまとめていきますので、これからポリシーを
AWS Loft好きのKyoです。CLIも好きで修行中です。 AWS CLIでスイッチロールする際の設定に困ったので情報を残しておきたいと思います。 前提 aws-cli/1.16.232 Python/3.7.3 Darwin/18.7.0 botocore/1.12.222 ベースとなるアカウントのIAMユーザから、別アカウントのIAMロールにスイッチロールして、CLIから操作を行う AWS CLIの設定は完了済み ~/.aws/にスイッチロール元のIAMユーザの aws_access_key_idとaws_secret_access_key が設定されている ~/.aws/config も以下の様に設定されている ~/.aws/config [default] region=ap-northeast-1 output=json 設定 スイッチロール先のプロファイルをtest001と名
はじめに AWSアカウント設計で環境毎(開発、検証、本番)に分けて権限分離を行うパターンをよく採用します。環境毎にIAMユーザーを環境毎に作成すると、ユーザーの追加、パスワードや権限の変更、ユーザーの無効削除が負担となる為、スイッチロールを利用しています。スイッチロールは便利なので設定方法の記事を多く見るので利用されている方も多数いらっしゃると思っています。ただ、スイッチロールを導入した後の運用をどうするか？この悩みがなかなか解決できなかったのでスイッチロールの運用について考えてみました。 AWSアカウント設計の構成例 AWSアカウントを環境毎に分割した設計例は、以下の通りです。 登場人物と役割は、以下の通りです。 Adminメンバー：すべての環境にすべての操作が可能 開発メンバー：開発、検証環境にアクセス可、操作制限あり 運用メンバー：本番環境にアクセス可、操作制限あり 登場人物毎にIA
このアクション、タグベースの認可 ないし リソースレベルのアクセス許可 に対応してる？ IAM ポリシービジュアルエディタでお手軽に確認しちゃおう | DevelopersIO
コンバンハ、千葉（幸）です。 私は AWS を触り始めてからかれこれ5年ほど経とうとしていますが、これまで IAM ポリシーを作成する際には「それっぽいベースを拾ってきてからの気合の JSON 直編集一本勝負」でしか闘ってきませんでした。それしか知らなかったのです。 正確に言うとビジュアルエディタという存在自体は知っていたのですが、「そんなハイカラなものは私には合わないであろうきっと」、その一心で使うのを避けてきました。 このたび戯れにビジュアルエディタを触ってみたところ、意外と便利ではこれは……という思いに駆られたので、どこに嬉しさポイントがあるのかを記していきます。 目次 IAM ポリシーのビジュアルエディタ とは タグベースの認可 とは リソースレベルのアクセス許可 とは ビジュアルエディタを使うと嬉しいところ 依存アクションがある場合にわかる アクションが対応するリソースタイプが確
コーヒーと DiveDeep が好きな木谷映見です。 皆さん、IAM を利用する際、「AssumeRole」というアクションを目にしたことはありますか？恐らく多くの方がかなりの回数目にしているのではないでしょうか。 私は特にこの「AssumeRole」というアクションが大好きです。目立たないけれど、いつもたくさんのサービスの裏で活躍している究極の縁の下の力持ち、いいやつですよね。 本日は AssumeRole について DiveDeep していきます。 IAM ロールはかぶると力を得る帽子 AssumeRole とは アイデンティティベースのポリシー リソースベースのポリシー IAM ロールの信頼ポリシー IAM ユーザーが引き受ける（かぶる）場合 例外 AWS リソースが引き受ける（かぶる）場合 IAM ロールを「引き受ける」「かぶる」とは さいごに 参考 ひとりごと IAM ロールはか
技術三課の杉村です。これからAWSを本格的に利用していこうと思っている方のために、AWSにおけるセキュリティの基本であるAWSアカウントとIAM (Identity and Access Management)の違いについて解説します。 AWSビギナーの方でも理解いただけるよう表現を抽象化したり、あえて深く説明していない部分もありますが、まずは概要を理解するためのものとお考えください。 1. AWSアカウント 1-1. AWSアカウントとは AWSアカウント（エーダブリューエスアカウント）は、身近な言葉で言うと「テナント」です。 AWSを利用したい、と思ったときは、まずAWSもしくはAWSのパートナーから "テナント" すなわちAWSアカウントを払い出してもらいます。 アカウントという言葉からは「Active Directoryのアカウント」のように個人に紐づくアカウントを想像してしまう方
こんにちは、Lambdaから別アカウントのリソースにアクセスする際にはAssumeRoleを行い一時的な権限を取得する必要があります。こちらの実装時にハマりましたので実装した手順をまとめたいと思います。 実装前にこちらのサイトを参考にEC2から他リソースのS3にアクセスする内容を試しました。とても分かりやすかったのでおすすめです。 別アカウントのS3バケットを利用する手順 手順 実装する内容は、図のようにアカウントAのLambdaからアカウントBのリソース(DynamoDBとS3)の読み込みを行うことです。 実装時にはこちらのリンクを参考に設定事項を確認しました。 別の AWS アカウントからロールを引き受けるように Lambda 関数を設定するにはどうすれば良いですか? アカウントBの設定 まずはアカウントBに必要な設定を行います。ここでは以下の3つを作成します。 アカウントAでリソース
皆さん初めまして、セキュリティ部の池添です。 仕事何やってるの？と聞かれるとつい面倒くさくなり、なんかセキュリティ色々と答えてしまうようなポジションやってます。 本記事では、Amazon EKS（以下EKS）の監査ログ周りがちょっとイケてないなーと思い、色々調べた結果を共有させて頂こうと思います。 はじめに 何がイケていないと思ったのかと言いますと、EKSのドキュメントを参考に設定を行うと、IAM Role利用時においてはEKSコントロールプレーンの監査ログのユーザ識別性が弱すぎる、と。 どういうことかと言いますと、弊社のAWSアカウントはIdP連携によるSSO化がされており、ログインをするとIdPから渡された情報を元にIAM Roleへのマッピングが行われます。ログイン後はAssumeRoleされた状態になるため、IAM RoleとEKSコントロールプレーン間でロールマッピングを行い利用
「Amazon EKSベストプラクティスガイド (セキュリティ編)」を読み解く (1)アイデンティティとアクセス管理 | DevelopersIO
みなさん、こんにちは！ AWS事業本部の青柳＠福岡オフィスです。 先月 (5/18) のことになりますが、AWSから「Amazon EKS Best Practices Guide for Security」という文書が公開されました。 この文書は文字通り「EKSを構築・運用する際のセキュリティ面におけるベストプラクティス」をまとめたガイダンスとなっています。 今回公開されたのはセキュリティに関するベストプラクティスですが、今後「パフォーマンス」「オペレーショナルエクセレンス (運用改善)」「コスト最適化」「信頼性」に関するものも公開される予定だそうです。 今回公開された「セキュリティ」に関するベストプラクティスガイドは、以下の10の章で構成されています。 アイデンティティとアクセス管理 (Identity and Access Management) ポッドセキュリティ (Pod Sec
CodeBuildのビルド内でAssumeRole(クロスアカウントアクセス)する方法とハマった話 | DevelopersIO
こんにちは、佐伯です。 CodeBuildからAssumeRoleする方法はズバリこれだ！ってエントリがなかった気がするので書きました。今更感がありますがご了承ください。また、CodePipelineで少しハマったので共有目的で本エントリを書きました。 CodeBuildのビルド内からAssumeRoleする方法 ビルド内からAssumeRoleするための設定に焦点を置いています。その他もろもろの設定は省いていますのでその点ご注意ください。 AWSアカウントの定義 AWSアカウントは便宜上以下のような名称として定義しておきます。 AWSアカウント名 AWSアカウントID 備考 account-a:IAMロールの作成 IAMロールの信頼関係にaccount-bを信頼するポリシーを設定します。設定するプリンシパルはAWSアカウントを信頼する or CodeBuildサービスロールを信頼するどち
ABAC について思っていること書いていこうと思います。 2021/08/20 追記 以下登壇スライドで改めて説明しています。こちらを御覧ください。 [前提] そもそも ABACとは何か？ ABAC は Attribute-based access control のそれぞれ頭文字です。 日本語では「属性ベースのアクセス制御」です。 AWSにおける ABACは タグを活用する ため、 「タグベースのアクセス制御」と言っても同じです。 以下 ABACのイメージ図です(AWSドキュメントからの引用) 画像: AWS の ABAC とは - AWS Identity and Access Management 上図では 各ロールやリソース(バケットオブジェクト, インスタンス) に マーク(ハート、太陽、雷) が付いています。 ハートマークのロール は ハートマークのリソースのみ アクセスできる
【小ネタ】AWS Extend Switch Roles にて行うべきと思う設定 | DevelopersIO
複数のスイッチロールを管理出来る AWS Extend Switch Roles について今更ながら知ったことを展開する記事です。 こんにちは、高崎＠アノテーションです。 はじめに 現在、多数の AWS アクセスロールを切り替えるために AWS Extend Switch Roles の Chrome 版を使用していますが、これがなかなか便利です。 この拡張機能において、最近気付いた便利な設定をチーム内で展開したところ、案外知られていなかったので小ネタとして記事にしてみました。 皆様のご参考になれば幸いです。 AWS Extend Switch Roles とは 通常、AWS でスイッチロールする時はマネージメントコンソールからアカウント ID とロール名を入力して切り替え、履歴からもアクセス出来ます。 しかしながら、ロール履歴には 5 つまでしか残すことが出来ず、その都度入力が必要になる
AWS活用のガードレール「IAM」の「Permissions Boundary」でアクセス境界を設定するには
AWS活用のガードレール「IAM」の「Permissions Boundary」でアクセス境界を設定するには：AWSチートシート 「Amazon Web Services」（AWS）活用における便利な小技を簡潔に紹介する連載「AWSチートシート」。今回は、「AWS IAM」の「Permissions Boundary」を利用したアクセス境界の設定について。 「Amazon Web Services」（AWS）活用における便利な小技を簡潔に紹介する連載「AWSチートシート」。 利用者によるAWSリソースに対するアクセスと認証を管理する「AWS Identity and Access Management」（IAM）は、AWSを使うなら最初に学習、利用するサービスの一つといっていいほど基本的なサービスです。 多くの人にとっては「IAMユーザー」「IAMグループ」「IAMロール」「IAMポリシー
こんにちは、森田です。 研修中に、各部署でスイッチロールを付与してもらっていますが、そもそもスイッチロールとは何者なのかを理解していなかったので、実際に色々試しながら理解してみます。 スイッチロールとは IAMの機能の1つで名前の通り、アカウント切り替え用のロール（役割）を提供します。 例えば、下図の場合です。 会社などに属している場合、部署やサービスごとでアカウントを分けることがあります。 この時、スイッチロールを使用せず、コンソールにログインする場合、アカウント ID、ユーザ名、パスワードがそれぞれで必要となります。 上図の場合アカウントが3つなので、何とかなりそうですが、 例えば、より多くのアカウントを切り替える場合はその分管理する情報も増えてしまうため、とても大変になってしまいます。 そこでスイッチロールでは、アカウントを切り替えるために任意のアカウントに対して、一時的な権限を発行
AWS CLIからCloudFormation でユーザとロールを作成して、流れるようにスイッチロールの確認をしてみた | DevelopersIO
AWS CLIからCloudFormation でユーザとロールを作成して、流れるようにスイッチロールの確認をしてみた 最近は、ABACばっかりやってるAWS 事業本部 梶原＠福岡オフィスです。 ABAC(属性ベースのアクセスコントロール ）を実施する際、ポリシーは同一にして、スケールすることができるのですが、ユーザやロールの確認作業は必要になってきます。 とはいえ、様々な属性値のユーザの確認作業を手作業でやるのは結構大変です。 ということで検証作業を楽にするため、ユーザー作成、ロール作成部分をTemplate化しました。必要に応じて修正（タグ値を追加など）して、ご自由にお使いください また流れで、ロールの検証を行いたいため、スイッチロールを楽にするために認証情報を取得しやすくしています。 credentialsの設定や、configの設定って微妙にはまりがちなのでなるべく簡単に定型作業で
概要 AWS IAM Identity Center 昔はAWS SSOと呼ばれていたました これを使うことで、複数AWSアカウントのIAMを統一的に管理することができます 複数アカウントのIAM管理手法はいくつかあります スイッチロールによる管理との比較、メリットについては 株式会社PLAN-Bさんがまとめてくれています 下記記事がとても分かりやすいと思います IAM Identity Centerは既存のIAMユーザーと競合しないので、段階的に一部のユーザーだけ試してみるといった運用も可能です 同じユーザー名でも問題ありません 今回は以下のようにaccountA、accountBに存在するyamasitaアカウントをIAM Identity Centerのyamasitaに移行するまでの設定をやってみます 以下のようにログインのURLが変わりますが、ログイン後の使用感は変わりません 実
IAMのWeb Identity Federationの理解にPlaygroundを試したら捗った | DevelopersIO
IAMのWeb Identity Federationが便利そうだけどどういう仕組みかがよくわからないってなりませんか。 用語がたくさんあったり若干入り組んでいるので私は苦しみました。苦しみながら ドキュメント を読んでいたらWeb Identity Federation Playgroundが理解に役立つと書いてありました。 なので実際に試してみました。 Web Identity Federationとは AWSリソースにアクセスするにはアクセスキーが必要になりますよね。 AWS CLIとかでアクセスキーを使用するのであればIAM ユーザーを作成して設定すれば問題ないですが、モバイルアプリやWebアプリに対して直接アクセスキーを埋め込むことは推奨できる行為ではありません。 また独自のIDをAWS側で管理したりカスタムサインインコードを書くのも非常に手間です。 これらの問題をさけつつAWS
大阪オフィスのちゃだいんです。 IAMのカスタムポリシーを1から作るぞってなったら、みなさんどうしてますか？ ポリシーを最初から作るの、なかなか骨が折れますよね。 今日は、私の作成方法を紹介してみようと思います。（もっといい方法があるって場合はこっそり教えてください） 要件 例えば、このようなIAMポリシーを作成したいとします。 対象はIAMユーザー AWS Systems Manager の Run Command の実行のみ許可 実行するコマンドのタイプを自己所有のドキュメントのみに限定し CLIでもマネジメントコンソールからでも可能 自己アカウント内のEC2に対して、すでに作成済みのスクリプトのみを実行する権限だけ与えたい。そんな場合と仮定します。 1. まず、類似したポリシーのサンプルが公式ドキュメントにないか検索する これはいわゆる検索力が物を言います。 AWSドキュメントの中に
Amazon Web Services ブログ 詳解: IAM Roles for Service Accounts この記事は Diving into IAM Roles for Service Accounts (記事公開日: 2022 年 2 月 28 日) を翻訳したものです。 AWS 上で Kubernetes ソリューションを設計するときにアーキテクトが直面するよくある課題は、コンテナ化したワークロードに対して、AWS サービスやリソースへのアクセス許可をどのように付与するのかという課題です。AWS Identity and Access Management (IAM) は、最小権限の原則を保証するために、誰がどの AWS サービスやリソースにアクセスできるかを指定できるきめ細かいアクセス制御を提供します。しかしながら、ワークロードが Kubernetes で実行されている場
吉川@広島です。 早速ですが、AWSにおけるスイッチロールの設定手順をまとめてみましたので紹介します。 前提 以下の想定で考えます。 AWSアカウントA この配下にIAMユーザaが存在する（MFA必須） AWSアカウントB この配下にIAMロールbを作成し、IAMユーザaからスイッチできるようにする 2つのAWSアカウントがあり、アカウントAのユーザaはすでに存在するものとします。ユーザaからアカウントBのロールbにスイッチできるように設定していきます。また、IAMユーザのMFAは必須とします。 IAMポリシー作成+IAMユーザにアタッチ まずアカウントAで作業します。 下記のようなIAMポリシーを作成します。 { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Ac
Amazon CognitoのUser Groupを利用した権限管理について本気出して考えてみた。 - Qiita
パーソルプロセス＆テクノロジー株式会社のAdvent Calendar 19日目の記事です。 Azureの記事が多い中ですが、堂々とAWSの記事を書いていこうと思います。 今回は何番煎じかわかりませんが、Amazon Cognitoを利用して役職や階級の概念を持つサービス内の権限管理を行います。 順を追って構築していくので、記事を読み終わった際に 権限管理が可能な環境が構築できる状態 になっていただければ幸いです。 あくまで『権限管理を行う』が目的です。個々の解説は適当なので、公式のドキュメントを合わせて読んでみてください。 不明点あれば質問いただければ返答します(正しい答えが返ってくるとは言っていない。) 最初に Cognitoは、認証認可、またユーザーの管理なども兼ね備えたフルマネージドなサービスです。 GoogleやFaceBookを利用したソーシャルログインも実現することもできます
About security hardening with OpenID Connect - GitHub Docs
Overview of OpenID Connect GitHub Actions workflows are often designed to access a cloud provider (such as AWS, Azure, GCP, or HashiCorp Vault) in order to deploy software or use the cloud's services. Before the workflow can access these resources, it will supply credentials, such as a password or token, to the cloud provider. These credentials are usually stored as a secret in GitHub, and the wor
Medium
You can find (just about) anything on Medium — apparently even a page that doesn’t exist. Maybe these stories will take you somewhere new?
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IAMユーザーのアクセスキー作成を簡単に通知して敏感になる - NRIネットコムBlog
1つの terraform で複数 AWS Account をまとめて構築・管理する - エムスリーテックブログ
[Python] Boto3以外でV4署名リクエストを行う | DevelopersIO
AWSサービスに渡すIAMロールを制限する | DevelopersIO
【AWS】AWS APIの認証・認可の仕組みを理解する【Signature V4】 - Qiita
AWSのポリシーを使いこなそう ポリシー設計につまづかないためのポイントを整理
【小ネタ】AWS CLIでスイッチロールして作業を行うための設定をやってみた | DevelopersIO
【IAM】スイッチロールの運用について考えてみた | DevelopersIO
AssumeRole について DiveDeep する - サーバーワークスエンジニアブログ
AWSアカウントとは？IAMとは？【ビギナー向け】 - サーバーワークスエンジニアブログ
Lambdaから別アカウントのリソースにアクセスしてみる | DevelopersIO
AuditableなEKSコントロールプレーンログを目指して | GREE Engineering
AWSのABAC(タグに基づいたアクセス制御)の設計/運用のポイントを考える | DevelopersIO
スイッチロールをやってみた | DevelopersIO
AWS IAM Identity CenterでIAMアカウントを統一する
[初心者向け] IAMカスタムポリシーを最初から作る方法の一つ | DevelopersIO
詳解: IAM Roles for Service Accounts | Amazon Web Services
スイッチ用のIAMロール作成手順 | DevelopersIO
dev.classmethod.jp
tm-choco-1127.hatenablog.com
musasabilife.hatenablog.com
news.yahoo.co.jp
weekly.ascii.jp
weekly.ascii.jp