1

Background:

We have product development teams, where each team has one or two QA engineers. They run tests from their local machines. Here is what they require:

  • Application credentials (a clientId and a clientSecret), which enable them to login and retrieve an access token via a login API service to test APIs.
  • Third party free trial login/passwords to test integrations with third party services. The free trial accounts expire after 30 days and then need to be recreated.

Challenges we're facing

  • Application credentials are generated by a team lead or senior developer. However, our IT team has sole access to the secret manager tool we use, so this requires engineers to share the secret they generated in our proprietary chat system. This does not seem secure to me.

  • According to Gleb Bahmutov, a core committer on the Cypress testing framework, passwords for test credentials should be Kept secret in e2e tests. We do see the value in that, since test credentials can be used to conduct flanking attacks in some cases. He doesn't commit passwords, but he injects the password via environment variables, which may not be a secure practice.

Questions:

  1. Who should own the application secrets? Do IT Security professionals manage them exclusively, or should the owners be the same people who generated the secret? (We're sharing them in chat in order to get them to the people who can add them.)

  2. The integration test accounts are transitory in nature and expire every 30 days. Do these really need to be treated as highly sensitive secrets stored in the secret manager? Can these go directly in the codebase? If not, where should they go? If they belong in a secret manager, how can these be managed so that the QA engineers don't face unnecessary struggles in keeping them up to date? Are these transitory, free trial test accounts really secrets?

I've searched the Internet repeatedly and cannot find much material on what is and isn't a secret, just technical documentation about how secret managers and key management stores work. I know how to integrate with them and have helped many of our teams get setup, but I'm looking for practical information on how to help others determine exactly what the best practices are for using secret managers in terms of what to store and who should manage them. I'm happy to be pointed to documentation that will help me understand this better.

jmort253
  • 201
  • 1
  • 6
  • 2
    What a secret is and who should own them is all down to the accountability required and the harm that can occur if an unauthorised person gains access to the token. In other words, it's purely a risk calculation. – schroeder Jun 02 '23 at 07:28

1 Answers1

2

Wikipedia defines secrecy as “the practice of hiding information from certain individuals or groups who do not have the "need to know", perhaps while sharing it with other individuals.” Thus, a secret is information that is intended to be restricted to people with the need to know.

How much effort you need to use to protect secrets depends on what the consequences of unintended exposure are. When you consider the consequences of exposure, you may want to think about things beyond the data that these accounts control. For example, if these credentials are used as part of a brute force or other attack on the platform, or to transmit illegal or unacceptable (e.g., hateful, defamatory, pornographic) information, then your company might be associated with the bad acts, which might have reputational or legal consequences. Similarly, in such a case, you might also be prohibited from creating new accounts or otherwise have restricted access in the future, which might impact your ability to use and test your integrations.

Personally, I find it a prudent course of action to always keep credentials in some sort of secret store or password manager. This encourages good security practices and avoids staff needing to consider the consequences of exposure in depth, since the rule is simple: if it's a credential, it needs to be stored securely.

One approach that could be helpful is to use some sort of shell or bastion host which has access to certain development and QA secret stores that can be used for this purpose, and then write a tool which can export those as needed into the user's test machine (ideally, but not necessarily, in some sort of encrypted form). I've worked at places where VPN certificates are generated and transferred in this way, and it makes provisioning them very easy. If the credentials change, a user can update them with little work, and the risk of exposure is minimized.

Similarly, a password manager could be helpful in this regard if the credentials are partially or primarily browser-based. If your company's password manager has a command-line tool, then this could also work for automated tasks. Only the relevant users would have access to the specific vaults, and they would not be pasted in chat where they could be easily exposed.

bk2204
  • 9,434
  • 22
  • 20
  • Thanks for the reply @bk2204. We decided to store the test creds in the secret manager. We spent some time kicking around some potential scenarios where things could go wrong if they leaked, but in the end, we decided things are much simpler if we just put everything in the secret manager. Sometimes we won't know what could go wrong until it does go wrong. – jmort253 Jun 04 '23 at 17:04