Skip to content

Commit

Permalink
add new 'Compare to' section under ESC in docs (#11934)
Browse files Browse the repository at this point in the history 
* add new 'Compare to' section under ESC in docs

* Update content/docs/esc/vs/_index.md

Co-authored-by: aaronkao <[email protected]>

* Apply suggestions from code review

Co-authored-by: aaronkao <[email protected]>

* clone esc vs vault page for esc vs infisical content to fill in

* update content, add infisical page

* update footer get started section to be about ESC

* edit vault logo, CTA and get started guides

* ESC vs Infisical comparison (#12001)

* update comparision

* Update content/docs/esc/vs/infisical.md

* Edits

* Some small edits

* Differences paragraph edits

---------

Co-authored-by: Aaron Kao <[email protected]>

* Updated Vault page

---------

Co-authored-by: aaronkao <[email protected]>
Co-authored-by: arunkumar611 <[email protected]>
Co-authored-by: Aaron Kao <[email protected]>
  • Loading branch information
@shughes26 @aaronkao @arunkumar611
4 people authored Aug 14, 2024
1 parent 24a2f6d commit 5825b7d
Show file tree
Hide file tree
Showing 5 changed files with 402 additions and 0 deletions.
22 changes: 22 additions & 0 deletions content/docs/esc/vs/_index.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
---
title_tag: "Pulumi ESC Compared to Alternatives"
meta_desc: Learn how Pulumi ESC compares with alternative Environments, Secrets, and Configurations solutions.
title: Compare to...
h1: Compare Pulumi ESC to other solutions
meta_image: /images/docs/meta-images/docs-meta.png
menu:
pulumiesc:
weight: 7
identifier: esc-vs
aliases:
---

Pulumi ESC is centralized environments, secrets, and configuration manager for cloud applications and infrastructure. It provides the ability to create environments which are collections of secrets and configuration that can be versioned, branched, and composed inside other collections. ESC supports pulling and centralizing the management of secrets from 1Password, AWS OIDC, AWS Secrets Manager, Azure OIDC, Azure Key Vault, Google Cloud OIDC, Google Cloud Secrets Manager, Pulumi stacks, Vault OIDC, and Vault.

There are many tools that overlap with Pulumi ESC's capabilities. Many
of these are complementary and can be used together, whereas some are "either or" decisions.

Here are several useful comparisons that will help you understand Pulumi's place in the cloud tooling ecosystem:

* [HashiCorp Vault](/docs/esc/vs/vault/)
* [Infisical](/docs/esc/vs/infisical/)
173 changes: 173 additions & 0 deletions content/docs/esc/vs/infisical.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,173 @@
---
title_tag: "Pulumi ESC vs Infisical"
meta_desc: Learn about the major differences between Pulumi ESC and Infisical.
title: Pulumi ESC vs Infisical
h1: Pulumi ESC vs Infisical
meta_image: /images/docs/meta-images/docs-meta.png
menu:
pulumiesc:
identifier: infisical
parent: esc-vs
weight: 2
aliases:
---

<style>
main table {
font-size: 0.94em;
}

main table th,
main table td {
width: 33.3%;
}
</style>

Choosing the right [secrets management](/what-is/what-is-secrets-management/) tool is important, and we want you to have as much information as possible to make the choice that best suits your needs. We’ve created this document to help you understand how Pulumi ESC compares with Infisical.

## What is Infisical?

Infisical is a secrets management tool that provides a centralized platform for managing and controlling access to secrets. It supports dynamic secret generation, encryption as a service, and comprehensive access policies.

## Pulumi ESC vs. Infisical: Similarities {#similarities}

Like Infisical, Pulumi ESC is a secrets manager for cloud applications and infrastructure. In both ESC and Infisical, secrets can be stored and accessed through a CLI, SDK, or Web editor interface. Granular access controls can be implemented across all secrets.

## Pulumi ESC vs. Infisical: Key Differences {#differences}

There are a couple of fundamental differences between Infisical and Pulumi ESC. First, ESC and Infisical differ in that Infisical can only add and manage secrets stored in Infisical. ESC adopts an open ecosystem approach, allowing you to pull secrets stored in most secrets and password managers during runtime and use them anywhere. This allows teams to use the best secrets management solution according their purposes and needs. Second, Infisical lacks the composability and hierarchical nature of ESC, which increases getting started speed and duplication of secrets. Third, ESC takes a software engineering approach to versioning with ability to add tags and import specific collections of secrets and configuration via those tags, similar to Docker. Fourth, ESC takes a more secure limited privilege path to provisioning dynamic short-term credentials as compared to Infisical.

Here's a detailed comparison of the two:

<table>
<tr>
<th>Feature</th>
<th>Pulumi ESC</th>
<th>Infisical</th>
</tr>
<tr>
<th colspan=3>Architecture</th>
</tr>
<tr>
<td>OSS License</td>
<td>Yes, Apache License 2.0</td>
<td>Yes, MIT expat license</td>
</tr>
<tr>
<td>Document Store</td>
<td>Yes</td>
<td>No</td>
</tr>
<tr>
<td>Key-value Store</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Open Ecosystem</td>
<td>Yes, supports pulling and using secrets from multiple sources including HashiCorp Vault, 1Password, AWS Secrets Manager, etc.</td>
<td>No, can only store and manage secrets stored in Infisical</td>
</tr>
<tr>
<th colspan=3>Developer Experience</th>
</tr>
<tr>
<td>Editing and Authoring</td>
<td>Yes, supports both GUI and powerful Document Editor with autocomplete, docs hover, and error checking</td>
<td>Limited, has GUI editor without YAML support</td>
</tr>
<tr>
<td>CLI</td>
<td>Yes, available as <code>esc</code> CLI or <code>pulumi</code> CLI</td>
<td>Yes</td>
</tr>
<tr>
<td>Client SDKs</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Declarative Provider</td>
<td>Yes, support via the Pulumi Service Provider, which allows management (create, update, delete) of collections of secrets and configuration as a resource through infrastructure as code.</td>
<td>No</td>
</tr>
<tr>
<td>Composability</td>
<td>Yes, simple set up of hierarchical environments that inherit values from imported environments</td>
<td>No, can only reference singular secrets from other environments and references have to be duplicated in multiple environments</td>
</tr>
<tr>
<td>Versioning</td>
<td>Yes, entire environments can be versioned and tagged and imported based on the specific version tags or revision numbers</td>
<td>Limited</td>
</tr>
<tr>
<td>Immutable History & Point in Time Recovery</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Values Can Be of Type Secret and Plaintext</td>
<td>Yes</td>
<td>No, values can only be secrets</td>
</tr>
<tr>
<td>Interpolate Values from Other Values</td>
<td>Yes, new dynamic values can be constructed through string interpolation</td>
<td>No</td>
</tr>
<tr>
<td>Branching / Personal Configs</td>
<td>Yes, environments can be forked for testing without rewriting entire environments and overriding specific values</td>
<td>Limited, requires careful copying since secrets need to be downloaded in plaintext locally and then uploaded</td>
</tr>
<tr>
<td>Compare Secrets across Environments</td>
<td>No</td>
<td>Yes</td>
</tr>
<tr>
<td>In-built Functions</td>
<td>Yes, support for functions like <code>toJSON, fromJSON, fromBase64, toString</code> allows data manipulation for any scenario</td>
<td>No</td>
</tr>
<tr>
<th colspan=3>Security and Compliance</th>
</tr>
<tr>
<td>Audit Logs</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Encrypted Secrets Storage</td>
<td>Yes, TLS is used for encryption in transit and unique encryption keys per environment are employed for encryption at rest</td>
<td>Yes</td>
</tr>
<tr>
<td>Access Controls</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Secure Dynamic Cloud Provider Credentials</td>
<td>Yes, uses OIDC flows to generate dynamic credentials. Available for AWS, Azure, and Google Cloud.</td>
<td>No, less secure as it requires access keys for highly privileged root accounts</td>
</tr>
<tr>
<td>OIDC Trust</td>
<td>Yes, trust relationships are established with third-party OIDC providers</td>
<td>No</td>
</tr>
<tr>
<td>Secure Environment Variables</td>
<td>Yes, the <code>esc run</code> CLI command can be used to specify which secrets are available as environment variables</td>
<td>No, all values are available as environment variables</td>
</tr>
<td>Plaintext Read Only Mode</td>
<td>Yes, ESC offers a <code>read</code> mode that allows reading only plaintext values while not being able to decrypt secrets or access dynamic credentials</td>
<td>No</td>
</tr>
</table>

{{< get-started-esc >}}
174 changes: 174 additions & 0 deletions content/docs/esc/vs/vault.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,174 @@
---
title_tag: "Pulumi ESC vs HashiCorp Vault"
meta_desc: Learn about the major differences between Pulumi ESC and HashiCorp Vault.
title: Pulumi ESC vs HashiCorp Vault
h1: Pulumi ESC vs HashiCorp Vault
meta_image: /images/docs/meta-images/docs-meta.png
menu:
pulumiesc:
identifier: vault
parent: esc-vs
weight: 1
aliases:
---

<style>
main table {
font-size: 0.94em;
}

main table th,
main table td {
width: 33.3%;
}
</style>

Choosing the right [secrets management](/what-is/what-is-secrets-management/) tool is important, and we want you to have as much information as possible to make the choice that best suits your needs. We’ve created this document to help you understand how Pulumi ESC compares with HashiCorp Vault, and how ESC and Vault can be used together.

## What is HashiCorp Vault?

HashiCorp Vault is a secrets management tool that provides a centralized platform for managing and controlling access to secrets. It supports dynamic secret generation, encryption as a service, and comprehensive access policies.

## Pulumi ESC vs. Vault: Similarities {#similarities}

Like Vault, Pulumi ESC is a secrets manager for cloud applications and infrastructure. In both ESC and Vault, secrets can be stored and accessed through a CLI, SDK, or editor interface. Granular access controls can be implemented across all secrets.

## Pulumi ESC vs. Vault: Key Differences {#differences}

There are a couple of fundamental differences between Vault and Pulumi ESC. First, ESC and Vault differ in that Vault is not open source, using the Business Source License model. In contrast, ESC is fully open source and Apache 2.0 licensed. Second, Vault only stores secrets, whereas ESC stores environments, secrets, and configurations. Third, ESC provides composability of collections of secrets and configuration. Environments can be composed together from multiple other environments, enabling easy inheritance of shared configuration.

## Pulumi ESC and Vault: Better Together

While there are differences and similarities between Pulumi ESC and Vault, they can actually be used together for a more powerful experience to store and manage infrastructure and application secrets. ESC environments can reference secrets stored in Vault. Through ESC, secrets in Vault can be organized as collections of secrets that can be versioned, branched, and composed inside other collections. With ESC, non-secret configuration can be stored alongside secrets in Vault. ESC enhances Vault, and they work better together.

Here is a summary of the key differences between Pulumi ESC and HashiCorp Vault:

<table>
<tr>
<th>Feature</th>
<th>Pulumi ESC</th>
<th>Vault</th>
</tr>
<tr>
<th colspan=3>Architecture</th>
</tr>
<tr>
<td>OSS License</td>
<td>Yes, Apache License 2.0</td>
<td>No, Business Source License 1.1</td>
</tr>
<tr>
<td>Hosting/management</td>
<td>Fully-managed SaaS service provided by Pulumi Cloud</td>
<td>Offers hosted cloud service and self-hosting, which requires significant management overhead</td>
</tr>
<tr>
<td>Key-value Store</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Open Ecosystem</td>
<td>Yes, supports pulling and using secrets from multiple sources including HashiCorp Vault, 1Password, AWS Secrets Manager, etc.</td>
<td>No, can only store and manage secrets store in Vault</td>
</tr>
<tr>
<th colspan=3>Developer Experience</th>
</tr>
<tr>
<td>Editing and Authoring</td>
<td>Yes, supports both GUI and powerful Document Editor with autocomplete, docs hover, and error checking</td>
<td>Limited, has a JSON editor</td>
</tr>
<tr>
<td>CLI</td>
<td>Yes, available as <code>esc</code> CLI or <code>pulumi</code> CLI. Supports injecting application secrets as environment variables and modifying secrets.</td>
<td>Limited, has a CLI but lacks the capabilities of injecting secrets as environment variables. The CLI is for modifying secrets only. </td>
</tr>
<tr>
<td>Client SDKs</td>
<td>Yes</td>
<td>Yes</td>
</tr>
</tr>
<tr>
<td>Declarative Provider</td>
<td>Yes, support via the Pulumi Service Provider, which allows management (create, update, delete) of collections of secrets and configuration as a resource through infrastructure as code.</td>
<td>No</td>
</tr>
<tr>
<td>Composability</td>
<td>Yes, simple set up of hierarchical environments that inherit values from imported environments</td>
<td>No, users have to create the structure themselves</td>
</tr>
<tr>
<td>Versioning</td>
<td>Yes, entire environments can be versioned and tagged and imported based on the specific version tags or revision numbers</td>
<td>Limited, secrets are individually versioned</td>
</tr>
<tr>
<td>Values Can Be of Type Secret and Plaintext</td>
<td>Yes</td>
<td>No, values can only be secrets</td>
</tr>
<tr>
<td>Ability to See Existing Secrets</td>
<td>Yes</td>
<td>No</td>
</tr>
<tr>
<td>Secret Referencing</td>
<td>Yes, environments can import secrets from another environment. Secrets updated from the referenced environment will automatically propagate to downstream environments</td>
<td>No</td>
</tr>
<tr>
<td>Interpolate Values from Other Values</td>
<td>Yes, new dynamic values can be constructed through string interpolation</td>
<td>No</td>
</tr>
<tr>
<td>Branching / Personal Configs</td>
<td>Yes, environments can be forked for testing without rewriting entire environments and overriding specific values</td>
<td>No</td>
</tr>
<tr>
<td>Compare Secrets across Environment</td>
<td>No</td>
<td>No</td>
</tr>
<tr>
<td>In-built Functions</td>
<td>Yes, support for functions like <code>toJSON, fromJSON, fromBase64, toString</code> allows data manipulation for any scenario</td>
<td>No</td>
</tr>
<tr>
<th colspan=3>Security and Compliance</th>
</tr>
<tr>
<td>Audit Logs</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Encrypted Secrets Storage</td>
<td>Yes, TLS is used for encryption in transit and unique encryption keys per environment are employed for encryption at rest.</td>
<td>Yes, Vault uses a security barrier for all requests made to the backend. The security barrier automatically encrypts all data leaving Vault using a 256-bit Advanced Encryption Standard (AES) cipher in the Galois Counter Mode (GCM) with 96-bit nonces.</td>
</tr>
<tr>
<td>Access Controls</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Secure Dynamic Cloud Provider Credentials</td>
<td>Yes, uses OIDC flows to generate dynamic credentials. Available for AWS, Azure, and Google Cloud.</td>
<td>Limited, requires the usage of root account keys. Only available for AWS.</td>
</tr>
<tr>
<td>OIDC Provider</td>
<td>Yes, Pulumi Cloud can be used as an OIDC provider from the Pulumi SDK, CLI, UI, and <code>pulumi-service</code> provider.</td>
<td>Limited, configuring Vault as an OIDC provider is only available from the CLI</td>
</tr>
</table>

{{< get-started-esc >}}
Loading

0 comments on commit 5825b7d

Please sign in to comment.