4 ms·

Why should someone use this when there are options within each Cloudprovider as well as Github and the like as well?

• dangtony98 4y ago
  In many cases, your infrastructure may be sprawled from local development to cloud providers and CI/CD pipelines like you mention; you may have many environments each requiring their own set of secrets. This phenomenon is known technically as "secret sprawl" (see here for a fuller read: https://www.conjur.org/blog/what-is-secrets-sprawl-how-to-avoid-it-with-secrets-management/ https://www.conjur.org/blog/what-is-secrets-sprawl-how-to-av...). There's a lot of issues with secret sprawl but I think the relevant one to your specific question mentioning other cloud providers would be having missing secrets across infrastructure (you introduce a new secret to the codebase and forget to update it everywhere else, as well as communicate it or sync it through to other developers on your team) — applications crash, you lose time. A big idea in secret management amongst others is the idea of *centralizing* your secret management in one place — update here, update everywhere. We help achieve that across your entire infrastructure and have a handy dandy CLI that also helps you inject secrets back into your programs (achieving secret management for local development with zero application dependencies) if you need that :D I may be misinterpreting your question actually — Unless you mean why use Infisical versus other alternatives on cloud providers like AWS Secret Manager / Parameter Store, Azure Key Vault, etc?
• heliodor 4y ago
  They gave some reasons at the top.