gcloud にカレントプロジェクトを設定しない派 - ぽ靴な缶
gcloud CLI にカレントプロジェクトをなるべく持たせないようにして暮らしている。 gcloud はデフォルトでカレントプロジェクトのリソースを操作する。操作するプロジェクトが 1 つなら良いけど、仕事でも遊びでもいくつもの GCP プロジェクトを扱っているので、うっかり異なるプロジェクトのリソースを操作してしまったり、意図しないプロジェクトに費用が計上されてしまうのが嫌だから。 カレントプロジェクトは設定しないようにして、gcloud を使う時は都度 --project=PROJECT_ID で渡すようにしている。 # カレントプロジェクトを確認するには以下のコマンドなど $ gcloud config get-value project $ gcloud config list # カレントプロジェクトの設定を消す $ gcloud config unset project ロー
GCPへの攻撃を考える。権限昇格について
はじめに 前回の記事では、どうやって認証情報を得てGCPへの初期アクセスを行うかというのが主題でした。 GCPへの攻撃を考える。認証情報の窃取（gcloudコマンド）編 https://zenn.dev/fire_fire_2/articles/e7484c7ca3702b さて、ここで取得した認証情報の権限は、高権限のものもあるでしょうが、大抵の場合そこまで権限がついてないもののほうが多いと思います。ということで、攻撃者が次の攻撃につなげるために行いたいのが権限昇格です。 GitLab RedTeamのChris Moberly氏が、GCPで初期アクセス後、攻撃者が行うであろう、情報列挙、権限昇格、侵害の目的達成の概説をブログで紹介しています。 Tutorial on privilege escalation and post exploitation tactics in Google
GCP Shared VPCを利用した全社共通ネットワークの運用におけるDedicated Interconnect利用設定の最適化手法 - ZOZO TECH BLOG
はじめに こんにちは。気がつけば4月でZOZOTOWNに関わって9年目を迎えるSRE部の横田です。普段はSREとしてZOZOTOWNのリプレイスや運用に携わっています。 本記事ではGoogle Cloud PlatformでShared VPCを採用し全社共通ネットワークを構築した背景とその運用方法について説明します。 ZOZOTOWNとパブリッククラウド専用線 まずはZOZOTOWNとパブリッククラウドを接続する専用線について説明します。 数年前まではZOZOTOWNを支える基盤は、ほぼ全てがオンプレミス環境で稼働しており、以下の課題がありました。 システムが密結合であること アジリティの低さ これらを解決するためにパブリッククラウドを活用したマイクロサービス化が日々進んでいます。 現在パブリッククラウドはAmazon Web Services（以下、AWS）とGoogle Cloud
AWSとGCPのVPN接続を複数パターン試してみる（高可用性（HA）VPN編） | DevelopersIO
はじめに データアナリティクス事業本部のkobayashiです。 AWSとGCPをセキュアな環境で接続してそれぞれのサービスを相互に利用できないか検証するためそれぞれのVPC間をVPNで接続してみました。 前回はGCPのVPNオプションにはClassic VPNでの接続方法をまとめましたので、今回は高可用性（HA）VPN接続の方法をまとめます。 Cloud VPN の概要 | Google Cloud 前回の記事 接続パターン Classic VPN接続 AWSでAWS VPN connectionを作成すると2つのIPSec tunnelが利用できます。 上のパターン（以降パターン1）ではそのうちの1本を利用するパターン、下のパターン（以降パターン2）は2本とも利用してフェイルオーバーに対応するパターンになります。 前回のエントリーではこのパターン1、パターン2の接続方法をまとめまし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
