jjdoe/ssm repository overview

⁠sup3rS3cretMes5age!

A simple, secure self-destructing message service, using HashiCorp Vault product as a backend.

Read more about the reasoning behind this project in the relevant blog post⁠.

Now using Let's Encrypt⁠ for simple and free SSL certs!

⁠Deployment

⁠Testing it locally

You can just run docker-compose up --build: it will build the Docker image and then run it alongside a standalone Vault server.

By default, the docker-compose.yml is configured to run the webapp on port 8082 in cleartext HTTP (so you can access it on http://localhost:8082⁠).

Optionally, you can modify the docker-compose.yml and tweak the options (enable HTTPS, disable HTTP or enable redirection to HTTPS, etc.). See Configuration options⁠.

⁠Production Deployment

We recommend deploying the project via Docker and a container orchestration tool:

• Build the Docker image using the provided Dockerfile
• Host it in a Docker registry (Docker Hub⁠, AWS ECR⁠, etc.)
• Deploy the image (alongside with a standalone Vault server) using a container orchestration tool (Kubernetes⁠, Docker Swarm⁠, AWS ECS⁠, etc.)

You can read the configuration examples⁠ below.

⁠Security notice!

Whatever deployment method you choose, you should always run this behind SSL/TLS, otherwise secrets will be sent unencrypted!

Depending on your infrastructure/deployment, you can have TLS termination either inside the container (see Configuration examples - TLS⁠), or before e.g. at a load balancer/reverse proxy in front of the service. It is interesting to have TLS termination before the container so you don't have to manage the certificate/key there, but make sure the network between your TLS termination point and your container is secure.

⁠Configuration options

• VAULT_ADDR: address of the Vault server used for storing the temporary secrets.
• VAULT_TOKEN: Vault token used to authenticate to the Vault server.
• SUPERSECRETMESSAGE_HTTP_BINDING_ADDRESS: HTTP binding address (e.g. :80).
• SUPERSECRETMESSAGE_HTTPS_BINDING_ADDRESS: HTTPS binding address (e.g. :443).
• SUPERSECRETMESSAGE_HTTPS_REDIRECT_ENABLED: whether to enable HTTPS redirection or not (e.g. true).
• SUPERSECRETMESSAGE_TLS_AUTO_DOMAIN: domain to use for "Auto" TLS, i.e. automatic generation of certificate with Let's Encrypt. See Configuration examples - TLS - Auto TLS⁠.
• SUPERSECRETMESSAGE_TLS_CERT_FILEPATH: certificate filepath to use for "manual" TLS.
• SUPERSECRETMESSAGE_TLS_CERT_KEY_FILEPATH: certificate key filepath to use for "manual" TLS.

⁠Configuration examples

⁠Plain HTTP

VAULT_ADDR=http://vault:8200
VAULT_TOKEN=root

SUPERSECRETMESSAGE_HTTP_BINDING_ADDRESS=:80

⁠TLS

⁠Auto TLS

VAULT_ADDR=http://vault:8200
VAULT_TOKEN=root

SUPERSECRETMESSAGE_HTTPS_BINDING_ADDRESS=:443
SUPERSECRETMESSAGE_TLS_AUTO_DOMAIN=secrets.example.com

⁠Auto TLS with HTTP > HTTPS redirection

VAULT_ADDR=http://vault:8200
VAULT_TOKEN=root

SUPERSECRETMESSAGE_HTTP_BINDING_ADDRESS=:80
SUPERSECRETMESSAGE_HTTPS_BINDING_ADDRESS=:443
SUPERSECRETMESSAGE_HTTPS_REDIRECT_ENABLED=true
SUPERSECRETMESSAGE_TLS_AUTO_DOMAIN=secrets.example.com

⁠Manual TLS

VAULT_ADDR=http://vault:8200
VAULT_TOKEN=root

SUPERSECRETMESSAGE_HTTPS_BINDING_ADDRESS=:443
SUPERSECRETMESSAGE_TLS_CERT_FILEPATH=/mnt/ssl/cert_secrets.example.com.pem
SUPERSECRETMESSAGE_TLS_CERT_KEY_FILEPATH=/mnt/ssl/key_secrets.example.com.pem

⁠Screenshot

⁠Contributing

Pull requests are very welcome!