Our team is spread all the cross the United States, as such whitelisting access to the W&B application by maintaining a massive IP Whitelist can be somewhat tedious, both for the person(s) maintaining the IP Whitelist and the engineers waiting for access.
I would like a way to disable the Cloud Armor without having to maintain a fork of this repo and just rely on oauth for access to our W&B instance.
What would be the preferred way to implement something like this? Two possibilities crossed my mind:
If allowed_inbound_cidr is empty, don't create the Cloud Armor security policy and don't bind it to the load balancer
Add a cloud_armor_enabled boolean var (or something) and conditionally create the cloud armor security policy if set to true, default to true.
The first option would mean the instance would default to being wide open, which is probably a bad security practice to encourage, so I would lean towards the second if only because it would be the most backwards-compatible way that wouldn't sacrifice any security in any way that someone isn't opting into.
Any feedback on preference or alternative suggestions would be appreciated.
Our team is spread all the cross the United States, as such whitelisting access to the W&B application by maintaining a massive IP Whitelist can be somewhat tedious, both for the person(s) maintaining the IP Whitelist and the engineers waiting for access.
I would like a way to disable the Cloud Armor without having to maintain a fork of this repo and just rely on oauth for access to our W&B instance.
What would be the preferred way to implement something like this? Two possibilities crossed my mind:
allowed_inbound_cidr
is empty, don't create the Cloud Armor security policy and don't bind it to the load balancercloud_armor_enabled
boolean var (or something) and conditionally create the cloud armor security policy if set to true, default to true.The first option would mean the instance would default to being wide open, which is probably a bad security practice to encourage, so I would lean towards the second if only because it would be the most backwards-compatible way that wouldn't sacrifice any security in any way that someone isn't opting into.
Any feedback on preference or alternative suggestions would be appreciated.