Secrets Usage History: What it is and why it matters

Everyone has secrets. In the realm of software engineering, these are usually API tokens, passwords, and encryption keys. We almost always need a method for sharing secrets, since the secrets need to be used by multiple developers and on multiple computers, for example when the software is running in the cloud. Whichever method we use to share secrets, there is always the risk that the secrets will fall into the wrong hands. The results can be catastrophic if a malicious actor obtains a secret — sensitive data may be stolen and your production system may be tampered with or shut down completely.

Monitor to Protect Secrets

The silver lining is that there is usually a delay between when a secret is leaked and when it is used in an exploit. Therefore, we have a chance to prevent serious harm if we are proactive about monitoring for unauthorized access to secrets. This is the motivation for tracking the usage history of secrets.

Zero serves as the single source of truth for your team's secrets, so it has the capability to tell you exactly when a secret was used and by whom. Diligently monitoring secrets usage history will allow your team to detect unauthorized access to secret credentials and act swiftly to cycle the affected API token or encryption key.

Usage History in Zero

Usage history can be viewed in Zero by selecting a project and switching to the Usage Stats tab:

Here, you can clearly see the exact time of the request, which secrets were requested, and the IP from which the request originated. In this case, the "B" icon means that the Braintree API secret was requested. (The full name of the secret is visible as a tooltip when hovering over the icon.)

While this table gives you most of the information you need to differentiate between expected and unexpected access to secrets, one challenge will be differentiating between known safe IP addresses and unknown IP addresses. If all of your developers work on prem and your service is hosted on prem as well, you would only expect to see one IP here. On the other hand, you could see many IP addresses in the list if your engineering team is distributed and your services are hosted in the cloud. In this case, it could be very difficult to tell which IPs are safe and which are not.

To help address this problem, the Zero team will soon update the Zero SDKs to accept a callerName parameter which will populate the caller name column seen in the table above. callerName can be any string you want, such as production-cluster, staging-cluster, or local-development. This feature will make it much easier to identify where requests for secrets are coming from.

The Next Step: Automatic Detection of Anomalous Access

The Zero team is hard at work on an automated solution for identifying unauthorized access to your secrets. When available, this solution will make the monitoring process much more hands off, increasing security for teams who don't have the time to be constantly scanning for leaks.

As always, remember that an ounce of prevention is worth a pound of cure, so be diligent about keeping your secrets safe by following security best practices in all steps of your DevOps workflow. In particular, take care not to commit secrets to git repositories, bake secrets into container images, or transmit secrets through insecure means like unencrypted email.