クラウドでもsuが出来る! GCPにPAM(特権管理)がついに登場
はじめに Linuxの良い所の一つにsuやsudoと言った特権管理の仕組みがあります。普段は通常アカウントで入って、例えばインストールなどの特権作業が必要な時だけsu/sudoで一時的な権限昇格が可能ですし、/etc/pam.dで誰がどのユーザにスイッチ出来るかなどは細かく制御できます。 一方で、クラウドの権限管理は悩みの種で、誤操作が怖いので普段はRead Onlyの権限にしておきたいのですが、手軽に権限を昇格する方法がありません。なので、別の管理者ユーザを作って、そちらでログインしなおしたり、それを半自動化するCyberArkやBeyondTrustといったPAM系ソリューション、あるいは最近流行りのCIEM(PAM機能を持つもの)を導入する必要がありました。 Azureでは結構以前からPIM(Privileged Identity Management)がネイティブで組込まれており非
拒否ポリシーでBigQueryのテーブル削除を無効にする
はじめに こんにちは、クラウドエース データ ML ディビジョン所属の疋田（ひきた）です。 珍しい苗字でなかなか覚えづらいと思いますので、是非「ヒッキー」と呼んでいただければ嬉しいです。 クラウドエースの IT エンジニアリングを担うシステム開発部の中で、特にデータ基盤構築・分析基盤構築からデータ分析までを含む一貫したデータ課題の解決を専門とするのがデータ ML ディビジョンです。 データML ディビジョンでは活動の一環として、毎週 Google Cloud (旧 Google Cloud Platform、以下「GCP」) の新規リリースを調査・発表し、データ領域のプロダクトのキャッチアップをしています。その中でも重要と考えるリリースを本ページ含め記事として公開しています。 今回ご紹介するリリースは、2023年8月7日にサポートするようになった、拒否ポリシーを介してのアクセス拒否機能です
GCPのIAMを整理し始めています(後編: Just-In-Time Accessを実現する) - Uzabase for Engineers
前回のまとめ jit-accessとは terraformでjit-accessを構築する 1. jit-accessアプリケーション用のサービスアカウントを作成 2. ネットワークリソースの作成 3. cloudrunの作成 4. モジュールの適用 5. IAM Conditionの追加 まとめ 前回のまとめ みなさんこんにちは。ProductTeam SREのkterui9019です。 前回の記事では、無秩序に作られていたIAMの設定を見直し、Googleグループの作成と組織体系に沿ったGCPプロジェクトのフォルダ階層を設計しました。しかし、最小権限の原則に従って設計したため、「障害対応時だけ強い権限をもったIAMロールを使いたい」というニーズを満たすことができませんでした。 今回の後編では、その問題を解決するためにGoogleが公開しているOSSであるjit-accessの紹介と、t
ECSからGCPの通信でWorkload Identityを導入して、GCPのサービスアカウントキーを撲滅した - Adwaysエンジニアブログ
初めまして！エージェンシー事業でアプリケーションエンジニアをしている22年新卒入社の内原です。 今回は、私が所属するチームのシステム(AWS ECS/Fargate)にWorkload Identityを導入してGCPのさまざまなサービスへサービスアカウントキーを利用せずにアクセスする方法について紹介と思います。 背景 課題 基礎編: Workload Identityの導入方法 1. IAMロールの作成 2. Workload Identity PoolとProviderの作成 3. Workload Identityとサービスアカウントの連携 4. 認証構成ファイルの取得 5. 認証構成ファイルを利用してECSでアプリケーションを実行 応用編: Workload Identity連携におけるアクセス制限について 方法1: 属性マッピングと条件 方法2: サービスアカウントの紐付け時の条
GitHubのSecret scanning alertsを有効化してセキュリティリスクを低減する - Qiita
はじめに 本記事はGitHubのSecret scanning alertsについて記載しています。 2023年2月28日、GitHubのブログでSecret scanning alerts are now available (and free) for all public repositoriesが公開されています。 上記ブログの情報を踏まえて、Secret scanning alertsがすべてのパブリックリポジトリで無料で利用できるようになりました。 従ってSecret scanning alertsを有効化することで、code, issues, description, and commentsに関するクレデンシャル情報が漏洩した場合、アラートを通知することができます。 Secret scanning alertsの設定 Secret scanning alertsを有効化する
BigQueryのIAM設定をアーキテクチャから理解する - Carpe Diem
概要 BigQueryはIAMロールを設定する際にハマる事が多いので、アーキテクチャを理解しておくときちんと権限付与することができます。 BigQueryのアーキテクチャ BigQueryのアーキテクチャは以下のように ストレージ コンピュート の大きく２つに分かれています。 ref: An overview of BigQuery's architecture and how to quickly get started | Google Cloud Blog そのため権限もこの２つを意識して設定する必要があります。 またストレージに関しては↓で説明したようなリソース階層（レベル）も意識する必要があります。 christina04.hatenablog.com 具体的には プロジェクト（組織、フォルダ） データセット テーブル と対象が細かく分かれています。 権限設定 BigQueryの
Google CloudのIAMの拒否ポリシーがGAになったので試してみる
※ポリシーとは、「主体」、「アクション」、「対象」を定義するバインディングをまとめた単位です。ポリシーの集合によって権限を管理します。以下、許可ポリシーの例（公式より引用）です。 { "bindings": [ { "role": "roles/storage.objectAdmin", "members": [ "user:ali@example.com", "serviceAccount:my-other-app@appspot.gserviceaccount.com", "group:admins@example.com", "domain:google.com" ] }, { "role": "roles/storage.objectViewer", "members": [ "user:maria@example.com" ] } ] } 許可ポリシーの継承 ポリシーは継承されま
OpenID 2.0 Shutdown Timetable | OpenID 2.0 (Migration) - Google Accounts Authentication and Authorization — Google Developers
Google の OAuth 2.0 API は認証と認可の両方に使用できます。このドキュメントでは、OpenID Connect 仕様に準拠し、OpenID Certified を受けている、認証用の OAuth 2.0 実装について説明します。このサービスには、OAuth 2.0 を使用した Google API へのアクセスのドキュメントも適用されます。このプロトコルをインタラクティブに試すには、Google OAuth 2.0 Playground の使用をおすすめします。 Stack Overflow でヘルプを表示するには、質問に「google-oauth」のタグを付けます。 OAuth 2.0 の設定 アプリケーションでユーザー ログインに Google の OAuth 2.0 認証システムを使用するには、 Google API Console でプロジェクトを設定し、OAu
秘密情報をGitLabに格納することなくGoogle Cloud / AWSに対して認証する - エムスリーテックブログ
エムスリーエンジニアリンググループ AI・機械学習チームの笹川です。 趣味はバスケと筋トレで、このところはNBAはオフシーズンですが、代わりにユーロバスケが盛り上がっていて、NBAに来ていない良いプレーヤーがたくさんいるんだなーと思いながら見ています。 夜ご飯を催促するためデスク横で待機する犬氏（かわいい） 今回は、パブリッククラウドへの認証に必要な秘密情報をGitLab自体に格納することなく、安全に認証する方法について紹介します。 CI/CDの実行時のパブリッククラウドに対する認証 ナイーブな手法とその問題点 OpenID Connectを用いた認証 Terraformでパブリッククラウド側の設定を記述する Google Cloudの場合 AWSの場合 GitLab CI/CDで認証する Google Cloudの場合 AWSの場合 認証ステップの共通化 まとめ We are hirin
Google Cloud の Cloud IAM の 拒否ポリシー - Qiita
はじめに IAMを操作していたところ、権限を付与する際に、基本ロールはもちろんですが、 事前定義ロールでも範囲が広いようなケースもあると思い、絞る方法を確認してみました。 IAM Roleの基本的な部分のおさらい 概要 IAMに対しては基本的にRoleを付与する形になり、ポリシーを直接付与するようなことはありません。 大きく基本ロール、事前定義ロール、カスタムロールがありまして、それぞれの役割に軽く触れます。 Role種別 基本ロール 少ないので具体的に書くと、オーナー、編集者、閲覧者がある。 位置づけ的には、オーナーがadmin、編集者がPowerUserっぽい、閲覧者がReadOnly PowerUserという表現はちょっと過大でもう少し権限が絞られているので、それプラス事前定義ロールを割り当てていたりすることもある 事前定義ロール 基本ロールはサービス全体に対する権限だったが、一つの
Google Cloud でサービス アカウントの権限借用（impersonate）を活用して SRE の権限を縮小させた話 - オールアバウトTech Blog
こんにちは。オールアバウト SRE 所属 の@s_ishiiと申します。 Google Cloud にはサービス アカウントの権限借用という機能があります。この機能を活用することで普段の運用をより安全にすることができます。この記事ではオールアバウトが導入・実践しているサービス アカウントの権限借用に関して解説します。 前提 オールアバウトでは SRE が全サービスのインフラを一元的に管理しています。このため SRE は全ての Google Cloud のプロジェクトに対してオーナー権限(roles/owner)を保持していました。 SRE メンバー全員がインフラを自由に変更できてしまうため、普段から Google Cloud のコンソール画面で設定を変更してしまわないよう注意しながら運用する必要がありました。 こうした状況を解決する手段としてサービス アカウントの権限借用の活用を検討し始め
BigQueryのデータセットにタグ付けをしてIAMでアクセス制御する
2022年6月6日のリリースノートでBigQueryデータセットへのタグ付けおよびIAMポリシーによるリソースアクセスをできるようになりました（プレビュー）。 何がうれしいのか BigQueryのデータセットへのIAMによるアクセス制御は従来でも可能でしたが、設定箇所がリソース（データセット）のオプション画面なので（個人的に）分かりづらいです。また、一覧性に乏しく、どのユーザー（またはグループ）がどのデータセットに権限が付与されているのかがIAMコンソール画面では分からず、データセットの権限設定まで見に行かないと分かりませんでした[1]。タグ+IAM Conditionsによるアクセス制御によって、IAM上で設定が完結できるうえに、IPアドレスや特定の時刻のみアクセスを許可することもできます。 タグとは ここでタグについて復習です。 「あれ？リソースにつけるやつだよね？前からデータセットに
面倒くさい権限管理をラクにしてくれるBiglake Tableの使い方！ - Qiita
まえがき 最近登場したBiglakeを使った所感を共有いたします。 色々公式ドキュメントには書かれているけど、既存のサービスに対して、具体的にどういった箇所で、どんな良さがあるのか発見したことを書きます。 BigQuery external tableと、BigLake tableの比較を前提として話します。 Biglakeとは データ ウェアハウスとデータレイクを統合するストレージ エンジン、BigLake です。BigLake は基盤となるストレージ形式やシステムを意識することなくデータを分析できるようにするもので、データの複製や移動が不要になり、コスト削減と効率化を図ることができます。 Google公式ドキュメントより引用： https://cloud.google.com/blog/ja/products/data-analytics/unifying-data-lakes-and
SSRF脆弱性を利用したGCE/GKEインスタンスへの攻撃例
電気が送電されました！万歳！！ 9/8が誕生日なのでお待ちしております。 http://amzn.asia/azuF53V 先日、以下のような記事を見た。 EC2上のAWS CLIで使われている169.254について EC2では、インスタンス内から http://169.254.169.254/ にアクセスすると、そのインスタンスに関する情報が取得できるようになっている。 そのため、SSRF脆弱性が存在し、レスポンスをユーザーに表示しているような場合には、http://169.254.169.254/latest/meta-data/iam/security-credentials/ にアクセスされることで、AWSのクレデンシャルを不正に取得される。 SSRFについてはここでは解説しない。以下の記事などを参照してほしい。 What is Server Side Request Forger
AWS の機能を GCP のサービスアカウントで認証して利用する | blog.monophile.net
概要 Google Cloud (GCP) のサービスアカウントのトークンを用いて認証し、AWS の機能を利用してみた。 背景 AWS を AWS の外から利用するには、IAM User とそれに付随するアクセスキーを発行して認証することが 簡単かと思われる。しかしながら、アクセスキーは長期的な認証情報のため、 セキュリティ面でのリスクが高く、なるべく用いることは避けたい。 今回、GCP のサービスアカウントを経由して認証することを試みた。 この方式であれば、GCP 内のメタデータサーバからの一時的なトークンによる認証、 もしくは個人の Google アカウントによる認証を用いることができる。 これによって、アクセスキーを用いる必要がなくなり、セキュリティリスク (e.g. クレデンシャルの漏洩) や運用コスト (e.g. 鍵のローテーション) を低減することできる。 目標 今回は個人に紐
GCP の Compute Metadata Credentials について
Google Cloud Platform(以降 GCP) の認証認可については GCP と OAuth2 などの記事があるが、 Compute Metadata credential そのものの解説はあまり十分にされているとは言えないので、今回一つの記事で説明する。 Compute Metadata Credentials と聞いてもピンと来ない人向けに書くと、「Cloud Run や Cloud Functions などの GCP のプロダクトから GCP の API を呼ぶのにサービスアカウントキーが必要ないこと」の裏側がどのように動いているかの話について説明する記事である。 Compute Metadata Credentials とは Compute Metadata Credentials は Google Cloud Platform(以降 GCP) の標準の credent
AWS - GCP の ID 連携を使い、 AWS CodeBuild で Terraform を使って GCP を管理 - スタディサプリ Product Team Blog
こんにちは。 SRE の @suzuki-shunsuke です。 Google Cloud Platform (以下 GCP) を Terraform で管理するように CI/CD を整備した話を紹介します。 背景 何度か本ブログで紹介したように、弊社では Terraform を使い AWS を始めとする様々なリソースを管理しています。 quipper.hatenablog.com しかし、 GCP はあまりちゃんと管理できていないという課題がありました。 弊社のサービスはほぼすべて AWS 上で動いており、 IaC が既に整備されています。 一方で GCP も以前から使っていますが IaC は整備されてなく、 SRE がたまに developer (以下 dev) から依頼を受けて、手で Project を作ったり IAM 周りを設定したりしていました。 IaC ができていないため、
それなりにセキュアなGKEクラスタを構築する - Qiita
はじめに GKEはGCPのサービスのひとつで、kubernetesのマネージドサービスになります。 GCPコンソールもしくはコマンドラインから、簡単にkubernetesクラスタを構築することができます。 リージョンの設定など初期設定を済ます必要はありますが、以下のコマンドを実行するだけでクラスタ構築が完了します。 趣味で触る場合はさておき、実際に業務でGKEを利用する場合はしっかりとセキュリティ面を考慮する必要があり、そのあたりを意識せずにGKEを利用するのは危険です。 本記事では、GKEのセキュリティに関するドキュメントを参考にし、それなりにセキュアなGKEクラスタの構築方法を紹介したいと思います。本来は最新情報などのキャッチアップも含め本家のサイトを参考にしていただくのが一番です。 このような機能があるんだなと、なんとなくの全体感を掴んでいただければ幸いです。 基本 Kubernet
BeyondCorp Remote Accessを支える技術 #1 GCP Cloud IAP connectorを試してみた | DevelopersIO
ども、ゲストのソラコム大瀧です。 在宅勤務のニーズが高まる昨今、Googleが提唱したBeyondCorp Remote Accessが話題ですね。 BeyondCorp Remote Access | Google Cloud VPNに代わって組織のシステムにセキュアにアクセスする手段をという触れ込みですが、「この製品を使えばBeyondCorp Remote Accessだ！」というものではなく、トラディショナルな境界セキュリティモデルに囚われずよりモダンなセキュリティソリューションを組み合わせてやっていこうというコンセプトモデルであり、Google社内のリモートアクセス構成をお手本にしつつ、日進月歩でその様相は移り変わるものと言えます。BeyondCorpのベースとなるセキュリティモデルであるZero Trust Networkを解説するネットワンさんの記事がわかりやすいです。 新解
GCP Cloud IAM Conditionsを試す - Qiita
はじめに 2020/2/28にGAになったCloud IAM Conditionを試してみたいと思います。 AWSのIAMは以前からリソース名やタグ、Source IPでの認可設定のConditionを記載できてましたが、GCPのCloud IAMにもCloud IAM Conditionという名称で同様の機能が追加になりました。 認可設定を付与する際の条件が設定できます。 何が出来るのか https://cloud.google.com/iam/docs/conditions-overview 現在、Conditionとして記載できるのは、大きく分けて時刻とリソースの2つになります。 時刻(request.time) リソース(resource) マニュアルに記載がある設定例 GCEインスタンス名などのリソース名やタイプを指定した制限(resource.name, resource.ty
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
