Envase Vault ============================================================================= |ev| is a service provided to store and manage secrets in a secure way. The service leverages |awssm|_ to store the secrets. It provides a REST API and a set of |awslb|_ functions to manage the secrets. |en| applications and services can leverage these interfaces to manage their secrets decoupling their implementation from the specifics of |awssm|_, making them more portable. .. contents:: Index Overview ----------------------------------------------------------------------------- The |ev| service provides a consistent interface to store and access secrets that |en| applications and services may need to access other services. This interface decouples |en| applications and services from the internals of |awssm|_ making them more portable. Another advantage of using |ev| is that |en| applications running outside of |en| AWS don't need to worry about providing credentials to access |awssm|_ directly. Instead, they will use the same credentials they use to access other |en| services. The |auth| process to communicate with |ev| through its REST API is the same that applications will use to communicate with other services. The service is deployed to three different environments to allow applications to integrate the service at different points of the development process. The |dev-guide| explains how applications and services should integrate with the different environments. The service also implements the concept of **secrets** and **organization secrets**, and separates those two concepts while maintaining a similar interface to manage them. This allows |en| applications and services to not only **manage the secrets they need**, but also to **manage safely the secrets their customers need**. Standard **secrets** are specific to an |en| application or service. All instances of the application use the same secrets to communicate with other services. By storing these secrets in |ev|, applications and services can access them when necessary without the need of deploying them and risk leaks of those secrets. **Organization secrets** are specific to an |en| customer. They may provide a set of credentials that an individual customer needs to interact with other applications and services. |ev| allows the application to separate and manage these secrets independently. Secrets vs. Organization Secrets: A Use Case Example ----------------------------------------------------------------------------- |ett| is a service that allows the different |en| TMS applications to track the status of a container. The different TMS applications implement different deployment mechanisms. For example, Profit Tools is a hosted application running on Windows. The computer where Profit Tools is running can be hosted by |en|, but can also be hosted by a Profit Tools customer within its network. At the same time, |en| TMS is a multitenant solution hosted in the cloud. This means that every |en| TMS customer is using the same cloud services. |en| customers may standardized in one particular TMS or use multiple ones. Regardless, they all use the same |ett| service. In order for the TMS application to trace containers, they need to publish them through |ecd|. This means the TMS needs to authenticate and then send a request to |ecd| to publish the containers. The |auth|_ process requires the TMS to provide a **client id** and a **client secret**. Instead of the application deploying the client id and secret into the user's machine to use them during the |auth|_ process, the application can access them from |ev| when needed. The client id and secret are common to all instances of the TMS application regardless of the customer who uses the instance; therefore, the information can be stored as a **standard secret**. Once containers are published, the |ett| service will check their status on a predetermined interval. This requires |ett| to access external services that provide the information. Some of these external services require credentials to be able to communicate with them. These credentials are not TMS credentials. Instead, each individual customer of the TMS will have its own set of credentials. The credentials for each individual customer can be stored in |ev| as **organization secrets**, and |ett| can determine the right set of credentials based on the customer's **organization id**. At the same time, some trace data providers will require credentials that have been issued for |en|. Regardless of the customer accessing the service, |ett| needs to authenticate as an |en| service. These credentials are stored as **standard secrets** in |ev|. Additional Information ----------------------------------------------------------------------------- .. toctree:: :maxdepth: 1 dev-guide docs-todo