Hey, how can we help?

All requests to the Doppler dashboard go through Cloudflare to help protect against malicious attacks on the site. Part of that includes a rate limit for requests being made to help prevent our service from being overwhelmed. Unfortunately, this can sometimes result in a temporary IP ban that blocks you from accessing the site under some conditions. If you're seeing an Error 1015 page as seen below, then you've hit such a temporary ban:

The ban is temporary and should clear up for you shortly after you hit it. Usually, this rate limit is hit by having a large number of tabs to our dashboard open. Right now, there's a polling request on the dashboard for Rotated Secrets (whether you have any or not) that is low enough that it doesn't cause issues typically, but if you have a lot of tabs open it can trip this rate limit. We have plans to improve this polling to prevent that from happening, but in the mean time keeping the number of tabs you have open to a handful should help prevent you from hitting this.

It's important to note that the ban is by IP address, so if you're working from a large office where many people are accessing the Doppler dashboard under the same IP address, this could potentially cause you to hit this more frequently. If this is happening to you, please open a support ticket and we'll see how we can assist you.

If you perform a helm upgrade and begin seeing the following error for your DopplerSecret resources:

Cannot change existing managed secret type from Opaque to .

then the problem is that you may not have followed our recommended upgrade process that includes upgrading the DopplerSecret CRD before upgrading the operator. Helm doesn't automatically perform CRD updates when you perform an upgrade, so you need to do it manually before each helm upgrade. To solve this problem, run the following commands:

helm pull doppler/doppler-kubernetes-operator --untar
kubectl apply -f doppler-kubernetes-operator/crds/all.yaml

After performing this upgrade, all of your existing DopplerSecret resources should recover after their next refresh (60 seconds by default), so wait for a couple minutes after upgrading the CRD and then check your DopplerSecret statuses again.

Note that this specific error occurred due to a change in the CRD between v1.3.0 and v1.4.0 of the operator. Not all operator versions include CRD changes, but it's best practice to apply the CRD update before upgrading every time regardless.

Doppler supports a variety of MFA/2FA options including OTP and Security Keys (e.g., Yubikeys). Enabling MFA/2FA is done via your account settings page, which is available via the Account option in the Avatar menu in the top right corner of the Doppler dashboard.

On that page, there's a section titled Multi-Factor Authentication (MFA) that looks like this:

If this section is not showing up on your account settings page, this is because your workplace has SAML SSO enabled. When SAML SSO is enabled, we hide these settings and essentially offload the MFA to the SSO IdP (e.g., if MFA is desired, then it should be enforced in Okta, Google, or whatever IdP you use when SSO is enabled). 

If you're seeing reserved Class E IP addresses (i.e., addresses in the 240.0.0.0 to 255.255.255.255 range) show up in your Account settings page for your Sessions or in Access Logs, then you're running into something called a Pseudo IPv4 address. This is a feature provided by Cloudflare to provide IPv6 compatibility with IPv4-only applications.

If an IPv6 request to Doppler comes through, Cloudflare will associate an IPv4 address pulled from the reserved Class E IP space with it. That IPv4 address is then what's passed on to the underlying application behind Cloudflare (i.e., Doppler). As a result, this IPv4 address will show up in Access Logs and your account Sessions list as your IP address.

In the future, we plan to disable this feature and display the IPv6 address in situations like this, but for now the pseudo IPv4 address will continue displaying.

If you've enabled SAML SSO on your account and the configuration wasn't quite right such that you're locked out, there is actually an easy way to get back into your account! When you enable SAML SSO, we send out an email titled SAML has been enabled that looks like this:

As you can see, it includes a Disable SAML button. The link that button follows is valid for 24 hours from the time you enabled SAML SSO. So, just click that button and it should disable SAML SSO on your workplace so you can log in via the same method you were using prior to enabling it.