Envase Vault
Envase Vault is a service provided to store and manage secrets in a secure way. The service leverages AWS Secrets Manager to store the secrets. It provides a REST API and a set of AWS Lambda functions to manage the secrets. Envase applications and services can leverage these interfaces to manage their secrets decoupling their implementation from the specifics of AWS Secrets Manager, making them more portable.
Index
Overview
The Envase Vault service provides a consistent interface to store and access secrets that Envase applications and services may need to access other services. This interface decouples Envase applications and services from the internals of AWS Secrets Manager making them more portable.
Another advantage of using Envase Vault is that Envase applications running outside of Envase AWS don’t need to worry about providing credentials to access AWS Secrets Manager directly. Instead, they will use the same credentials they use to access other Envase services. The Authentication/Authorization process to communicate with Envase Vault 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 Developer’s 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 Envase 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 Envase application or service. All instances of the application use the same secrets to communicate with other services. By storing these secrets in Envase Vault, 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 Envase customer. They may provide a set of credentials that an individual customer needs to interact with other applications and services. Envase Vault allows the application to separate and manage these secrets independently.
Secrets vs. Organization Secrets: A Use Case Example
Envase Track and Trace is a service that allows the different Envase 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 Envase, but can also be hosted by a Profit Tools customer within its network.
At the same time, Envase TMS is a multitenant solution hosted in the cloud. This means that every Envase TMS customer is using the same cloud services.
Envase customers may standardized in one particular TMS or use multiple ones. Regardless, they all use the same Envase Track and Trace service.
In order for the TMS application to trace containers, they need to publish them through Envase Connect Data. This means the TMS needs to authenticate and then send a request to Envase Connect Data to publish the containers.
The Authentication/Authorization 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 Authentication/Authorization process, the application can access them from Envase Vault 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 Envase Track and Trace service will check their status on a predetermined interval. This requires Envase Track and Trace 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 Envase Vault as organization secrets, and Envase Track and Trace 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 Envase. Regardless of the customer accessing the service, Envase Track and Trace needs to authenticate as an Envase service. These credentials are stored as standard secrets in Envase Vault.