As part of our Secure Software Development Life Cycle (SSDLC) at Unity, we’d like to share our credential management strategy. Managing tokens, keys, and credentials in code, otherwise known as secrets, can be a daunting process. By sharing these details, we hope others will benefit and learn from our journey.
A couple of years ago, the Unity Security team, along with our partners in the infrastructure teams, set their sights on tackling the problem of managing credentials. In a large, diverse environment such as Unity, projects can be written in one of many programming languages, developed in several different environments, and deployed through a number of continuous integration toolchains. This makes managing credentials an even more challenging task. In this blog post, we’re sharing our journey as well as open-sourcing our solution so others may follow suit.
So, we need to manage credentials. But what are they? A credential, also known as a secret, is any piece of information required by your service to perform a privileged operation on a resource or another service. This can be a token for an API, a password to log in to some service, an SSH private key for connecting to an external server, a set of credentials for writing to a storage bucket, or an RSA key for signing binaries. Regardless of its type, the information needs to be carefully guarded and known only to the parties involved in the transaction that uses it. Ideally, not even the developers working on the service should know it, or at the very least, they should not have constant access to this information.
The two goals of any solid credential management strategy are to ensure that credentials don’t fall into the hands of malicious actors, and deal with credentials in a way that doesn’t create unnecessary complications for developers. However, that’s easier said than done.
When establishing a credential management strategy, the team should anticipate a few common problems:
After careful deliberation, we’ve opted to use HashiCorp’s Vault. This credential management solution allowed us to address most of the problems we had in our sights. What’s more, a version of it is available as an open source solution.
Vault provided us with a solution for securely storing the credentials, tightly controlling access to them, and allowing users to retrieve them. Unfortunately, developers still had to manually integrate the Vault libraries into their projects in order to retrieve and use the credentials. Crucially, Vault still doesn’t address the nesting Russian doll problem. Yes, now we have a safe, secure place for storing the credentials, but accessing them still requires a token. This puts us in a much better position, but it pushes the problem one more level nonetheless.
To address the remaining issues, we looked into a few existing tools, but they didn’t match all of our requirements, especially when it came to user-friendliness. This is why we created Vault Secret Fetcher (VSF). VSF works by arranging the authentication through GKE/Kubernetes or Google Compute Engine to push the nesting Russian doll problem one level further away from the code while leaving the initial authentication to the orchestration or underlying infrastructure platform. This behavior can be easily modified to support any other infrastructure since Vault supports a wide array of authentication mechanisms.
All the developer has to do is to write the secret to Vault.
vault write secret/<YOUR PATH> token="..."
And then assign the path placeholder in their service’s environment.
TOKEN = ‘VAULTSECRET::{"path":"secret/sre/dev/TEST", "key":"token"}’
The credential-fetching flow looks like this:
Find more detailed information about the process in the project’s README.
Since we’re releasing Vault Secret Fetcher as an open source project, we’re inviting you to check it out and consider how it could help you with your projects. We also welcome your contributions.
In the future, we’ll be looking for ways to make Vault Secret Fetcher even more portable and allow it to support more platforms and use cases.
Is this article helpful for you?
Thank you for your feedback!