feat: add How Secrets Sprawl is Slowing You Down—And What to Do About It blog #13095
Conversation
|
Your site preview for commit 7208caa is ready! 🎉 http://www-testing-pulumi-docs-origin-pr-13095-7208caa5.s3-website.us-west-2.amazonaws.com. |
|
|
||
| As we keep adding new cloud resources and releasing new applications, the number of secrets we need to manage keeps growing: passwords, API keys, certificates, and more. And as this is not enough, we need to manage secrets across different systems and environments with different teams that need to access them; we end up with duplicates. | ||
|
|
||
| Let's have a look at a typical environment and see what teams use: Everything container-related may use Docker secrets or Kubernetes secrets. There is also a high chance that they might use cloud-specific secrets managers like Azure Key Vault, AWS Secrets Manager, or Google Secret Manager. In addition to these, there is a high chance that they might use HashiCorp Vault or some enterprise-grade secrets manager like CyberArk. |
There was a problem hiding this comment.
It would be interesting to actually give a very tangible example.
Imagine Alice, not her real name. When she first setup K8S at Acme Corp, Kubernetes secrets was a natural choice. Then X happened and her college Bob brought in AWS Secrets managers.....
Now a password needs to change, and Alice is spending so much time tracking everything down. Each step along the way made sense, but now she's stuck in Secret Sprawl (tm).
And tell the whole sprawl story from a very specific fictional team example, before switching to the ESC plug.
Co-authored-by: Adam Gordon Bell <[email protected]>
|
Your site preview for commit 143d94f is ready! 🎉 http://www-testing-pulumi-docs-origin-pr-13095-143d94f6.s3-website.us-west-2.amazonaws.com. |
Proposed changes
Unreleased product version (optional)
Related issues (optional)