Lambdas, Cloud Workers, and other
serverless vendors either do not allow static addresses or make using them problematic or insecure. If you cannot trust your infrastructure treats IP addresses as security critical, you cannot trust this method for authentication. You can add DNS as an abstraction over IP addresses, but now you also have to trust the unauthenticated unencrypted poisonable DNS infrastructure in your security critical infrastructure. Many other systems do rely on DNS security (like TLS thanks to ACME), but it is still an extra point of attack in this model.
One way to compensate is requiring credentials for your credential service. This has merits, but all the same problems putting credentials in your source did in the first place. Although, you've now just introduced a single point of failure. To understand the single point of failure, imagine what happens if that service is unavailable. Also, if your attacker has an exploit for this system, they may now have all of the credentials to all of your services. For a bit of history, the NSA documents showed that well funded attackers hunt sysadmins.
The biggest upside to this however is key rotation. No service knows the credentials or has them hard coded when done right. You can then generate and use new credentials automatically and continuously. I'm not a proponent of rotating keys all the time unless they've been compromised, but for those that are, this is often a compelling feature. Compromise by the way can just include when someone who was trusted should no longer be (retirement, termination, resignation, etc.).
Many people go this route as an attempt at isolating developers from production. I'll just say right now, if you can't trust your developers, hire ones you can. If I can run code on your machine, I can do just about anything I want.
Another method is to encrypt the credentials while they reside outside of your trust boundary but enable those trusted to decrypt them when needed. Two popular methods for doing this include git-crypt and git-secret. These are convenient because they look and feel almost identical to just putting credentials in the source code, but transparently encrypt them whenever they sit on an untrusted computer. They also allow you to open source your code without providing access to the secrets.
These work by encrypting and decrypting something from STDIN to STDOUT, applied using Git Attributes. Specifically, the clean and smudge filter attributes. Using the clean filter, a file can be modified transparently before it is added to git's index (and subsequently committed). Using a smudge filter, blobs in git can be transparently modified before being written into your working directory. The subtlety here is in key management. The
simple answer is use PGP, but a deeper discussion of this solution is set for a future post.
With this solution, development doesn't always require credential access. People using encrypted versions can still use and test the software without the functionality provided by the secrets. You can also allow users to drop in their own credentials. This means you can still have sysadmin only and developer only credentials if you want better production isolation.
While PGP has been around for what feels like forever, many people still find it hard to use and unintuitive. Thankfully it's essentially set and forget. The only complex time is when you have to create your keypair and when you create a new repo. When you're doing routine commit cycles it can be so invisible you forget it even exists from time to time.
Make sure you don't accidentally commit the credentials in the clear. This mistake is usually only made at the start of a repo, but can happen when you overwrite credentials in a locked repo. If you get them into your history, getting them out is possible but a pain as you'll have to rewrite the history. I often advise just rotating the keys when this happens to destroy the old credentials.
On the topic of key rotation, this method does nothing to help. You also don't gain any additional monitoring. It doesn't provide a backup in case you forget to backup your PGP keys or remember your password, nor can you see the credentials in any sort of website based git view. You've also added another tool to your build chain that developers will have to install, configure, update, and learn.
Don't think of any as your best choice. There are a large number of considerations that make each a good choice given a different situation. You have to think carefully about your trade offs in any engineering decision.
I hope this gave you a good introduction into threat modeling, authentication schemes, security fundamentals, and making trade offs. If you're just putting security credentials in your code, I strongly encourage you to think critically about the long term implications that has.