Price here. I’m evaluating Doppler for our tech stack.
In this use case, we’re writing data apps primarily aimed at Azure deployments with an eye to multi-cloud deployments. Apps are hosted in AKS, and secrets in the key vaults are being used to orchestrate settings with other services - various database services, Databricks, functions, etc.
The first thing I tried to do was see if I could sync values into Kubernetes – no obvious issues with the pull model yet – and a key vault. The latter failed as network traffic to the key vault is restricted, and I can’t seem to figure out what IPs Doppler pushes from when trying to apply its integration. The public IPs for doppler.com are apparently not their egress points. I would expect the same issue to be true for any firewalled deployments, so I’m a little surprised the search isn’t turning up anything.
Any suggestions?
Hi @pricehatfield and welcome to the Doppler community!
I’ll speak to our engineers to get our CIDR IP range for you and agree that we need to have this documented.
1 Like
Thanks, @ryan-blunden .
I didn’t make it far enough in the key vault integration wizard to tell - how will it authenticate? Do I end up authorizing an external service principal, or does it rely on a token-based method?
Hi @pricehatfield,
We don’t currently have static IPs in place for egress unfortunately but it’s something we can look into for the future.
For authorization, access is granted via an OAuth flow which installs the Doppler Azure Enterprise Application.
Did stable egress make it onto the roadmap? Locking down the traffic origins is a must in our environments.
Within the Azure context, vendors like Snowflake (assuming it’s deployed in the same cloud and region) that rely on app registrations will also provide the subnet IDs so traffic never has to leave the internal service network.
