Comments on the current Trusted IPs feature

Well, the CircleCI issues are keeping me busy and causing me to look at using tools like Doppler in very different ways.

My current focus is on restricting access, so restrict the fallout from any future issue such as the one that CircleCI suffered from. The Trusted IPs feature should be an ideal feature to build on, but it is currently limited in the following ways.

  • As I have posted before, there is an issue with the current configuration due to the fact that the list is for all tokens generated for a single config. This allows for a possible exploit where a system granted read-only rights is also able to use an r/w key if discovered.

  • You need to maintain a separate list per config and each entry can only be a single address or CIDR range. When trying to enter and maintain the IP addresses used by CircleCI build agents this gets out of control very quickly for just a single config. As I’m using Doppler to define each deployed system, each compiled code instant and each deployed application environment I have rather a lot of configs.

In addition to this I am guessing that there is a need for an easier way to allow common Cloud based CI tools (like Circle) to allow IP restricted access in addition to token based access.

That would not work too well as

  • The token is also the unique identifier used to select the config that you want to access, while also providing a way to register the access type - RO or RW.

  • Just about all Cloud based services like CircleCI use shared resources and so have many clients using the same IP addresses. So you can not just depend on the IP address for authentication.

  • Tokens allow access to be revoked for one reason or another, revoking an IP address would mean no future access for any process running on the IP address.

So IP lists are a security enhancement to tokens, rather than a possible replacement. As I noted in my original post a lot can be done to make IP based controls a lot more useful, as currently, you have to configure independent IP lists for each token you define.

Fully agree. I meant as an augmentation to tokens.

Sorry my comments were not clearer, CircleCI (as example) as a method to manage a range of IPs from which their service is hosted.

If Doppler can allow the AWS Config to be loaded into a centrally managed (across Doppler tokens/projects) it would be a very useful set of security suspenders to the belt project based tokens.

Without this I am basically relegated to opening 0.0.0.0/0 across all projects/tokens.

That is clearer,

yes, there is a lot that could be done to the current IP controls that would allow them to be useful in real-world situations. At the moment I would guess that the current implementation was done to meet a certain user case/requirement rather than be a general solution.

It is all most as if the Doppler team needs to find a solution that can handle the creation of lists of values and configurations with unique identifiers that can then be assigned in a secure way - I wonder where they could find such a system :slight_smile: