はじめに
LoadBalancer経由のCloud Storageへのアクセスに対するIPアドレス制御が可能になった。
https://cloud.google.com/blog/ja/products/identity-security/cloud-armor-adds-more-edge-security-policies-proxy-load-balancers
Cloud Armorに新たに追加されたエッジセキュリティポリシーの動作確認をする。
概要
Google CloudではLoadBalancer(CLB)にCloud Storage(GSC)をバックエンドバケットとして追加が可能で、
カスタムドメインで静的コンテンツを見せることができる。
今までCloud Storageをパブリック公開する場合は、アクセス制御はバケットの権限による全体へアクセスを許可するしか方法がなかった。
が、それに対してCloud Armorの機能追加のエッジセキュリティポリシーによってIPアドレスでのアクセス制御が可能となるので、それの動作確認をしていく。
設定
CLBとGCSの構成する
以下のように作成した
注意事項
この時点でCloud Armor のエッジセキュリティポリシーを使う上では、既にハマっているポイントがあったので紹介する。
※よく読めば防げた内容です。
- やりたいことを実現する場合、LBはネットワーク階層がプレミアムである必要がある
- Cloud CDNを有効にする必要がある(本来この作成時点ではバックエンドに対するCDNは有効にできず、先にCDN側で有効にしルールを設定する必要がある)
※Cloud CDNが必要な点については次のCloud CDNを構成するで記載する
CDNを構成する
以下のように作成した
特段実施したいことに絡む設定はないが、CDN自体は有効にせねばならない。
CDNが必要な理由
- 以下にも説明があるがあくまでもエッジセキュリティのため、キャッシュに対するフィルタリングや制限をすることが目的であり、GCSに直接で制限するものではない。そのため、キャッシュを効かせるためにCDNを有効にする必要がある。
参照：https://cloud.google.com/armor/docs/security-policy-overview#edge-policies
実際にアクセスする
実際にアクセスするとエッジセキュリティポリシーがしっかり効いていることが確認できる。
やはりエッジに対するポリシーであるため、FWのIP許可とは異なり、設定後、効くまでに若干時間を要する。
CDNを有効化しないといくらやってもエッジセキュリティポリシーのルールは効かず、IPアドレスを全拒否しようとしても、問題なくアクセスできる状態になってしまう。
1つお試し
上記の結果を受けて、CDNでキャッシュをしないように設定したコンテンツに対してもエッジセキュリティポリシーは効くのか、というのが気になったので試す。
※対象メタデータは以下参照
https://cloud.google.com/storage/docs/metadata?hl=ja#cache-control
結果
- no-cacheだとエッジセキュリティポリシーが効いているように見える
- privateでもエッジセキュリティポリシーが効いているように見える
これらのことからキャッシュに対して効いているというより、キャッシュに効かすために、各エッジ自体にセキュリティポリシーは効いていそう
参考までに確認方法
https://cloud.google.com/cdn/docs/troubleshooting-steps?hl=ja
所感
GCSに対するIPアドレス制限だ！と飛びついたものの、ちゃんと読めば分かる通り、エッジに対するセキュリティポリシーでした。
ただ、GCSに対するIPアドレス制限したいケースは私でも何回か経験しているので、優先する事項が何か(Cloud CDNが必要だとコストはかかるため)、にもよるかもしれませんが、開発や検証環境で制限するのが必要なケースは多いのではないか、と感じ、そういった場合利用できると思いました。