1-20 people - password manager (bitwarden, 1pass, etc.) 20-30+ people - SSO
50+ people - start assigning real roles to your SSO schema
1-5 services - secrets in CircleCI and password manager is good enough.
5+ instances - use a secrets manager like Vault.
10+ instances - start using a secrets manager locally as well for dev. Start to consider using well scoped IAM policies for each of your services and team members.
15+ instances - start to think about adding additional zero trust boundaries.
Of course, this is very rough. Depending on your regulatory/compliance requirements and how much revenue you’re bringing in and from who, you might have to do this stuff sooner. In general, it should go:
1. Centralize secrets even if you can’t easily revoke people (password manager).
2. Make things easily revocable and centralized (sso).
3. Make roles and access finer grain (RBAC).
4. ^ with automation between all of these steps where it makes sense.
Something I would warn anyone of is building your own auth/secrets core tooling. This stuff is incredibly complex because of the edge cases and it’s just not worth the risk you take on by saving money unless you have a really good core business reason to roll your own. It’s also dangerous to prematurely optimize and pay the SSO tax too early. You will find that a lot of engineers appeal to emotion when it comes to risk. Something extremely helpful is going through and actually assigning a security risk score for all your systems. This might be tedious, but it brings a lot of clarity to the conversation of “what do we want to build when? What risk can we take on at any given stage?”