Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Simple to use, simple to deploy, one time self destruct messaging service, with hashicorp vault as a backend

License

NotificationsYou must be signed in to change notification settings

algolia/sup3rS3cretMes5age

Repository files navigation

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

self-destruct

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

Now usingLet's Encrypt for simple and free SSL certs!

Frontend Dependencies

The web interface is built with modern vanilla JavaScript and has minimal external dependencies:

  • ClipboardJS v2.0.11 (8.9KB) - Copy to clipboard functionality
  • Montserrat Font (46KB) - Self-hosted typography
  • Custom CSS - Application styling

No external CDNs or tracking: All dependencies are self-hosted for privacy and security.

Total JavaScript bundle size: 8.9KB (previously 98KB with jQuery)

Deployment

Testing it locally

You can just rundocker-compose up -f deploy/docker-compose.yml --build or runmake build: it will build the Docker image and then run it alongside a standalone Vault server.

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

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

Production Deployment

We recommend deploying the project viaDocker and acontainer orchestration tool:

  • Build the Docker image using the providedDockerfile or runmake image
  • 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 theconfiguration examples below.

Security notice

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

Depending on your infrastructure/deployment, you can haveTLS termination eitherinside the container (seeConfiguration examples - TLS), orbefore 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, butmake sure the network between your TLS termination point and your containeris secure.

Helm

For full documentation for this chart, please see theREADME

Command Line Usage

For convenient command line integration and automation, see our comprehensiveCLI Guide which includes shell functions for Bash, Zsh, Fish, and WSL.

Quick example:

# Add to your ~/.bashrc or ~/.zshrco() { cat"$@"| curl -sF'msg=<-' https://your-domain.com/secret| jq -r .token| awk'{print "https://your-domain.com/getmsg?token="$1}'; }# Usageecho"secret message"| oo secret-file.txt

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. SeeConfiguration 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.
  • SUPERSECRETMESSAGE_VAULT_PREFIX: vault prefix for secrets (defaultcubbyhole/)

Configuration examples

Here is an example of a functionnal docker-compose.yml file

version:'3.2'services:vault:image:vault:latestcontainer_name:vaultenvironment:VAULT_DEV_ROOT_TOKEN_ID:rootcap_add:      -IPC_LOCKexpose:      -8200supersecret:build:./image:algolia/supersecretmessage:latestcontainer_name:supersecretenvironment:VAULT_ADDR:http://vault:8200VAULT_TOKEN:rootSUPERSECRETMESSAGE_HTTP_BINDING_ADDRESS:":80"SUPERSECRETMESSAGE_HTTPS_BINDING_ADDRESS:":443"SUPERSECRETMESSAGE_HTTPS_REDIRECT_ENABLED:"true"SUPERSECRETMESSAGE_TLS_AUTO_DOMAIN:secrets.example.comports:      -"80:80"      -"443:443"depends_on:      -vault

Configuration types

Plain HTTP

VAULT_ADDR=http://vault:8200VAULT_TOKEN=rootSUPERSECRETMESSAGE_HTTP_BINDING_ADDRESS=:80

TLS

Auto TLS
VAULT_ADDR=http://vault:8200VAULT_TOKEN=rootSUPERSECRETMESSAGE_HTTPS_BINDING_ADDRESS=:443SUPERSECRETMESSAGE_TLS_AUTO_DOMAIN=secrets.example.com
Auto TLS with HTTP > HTTPS redirection
VAULT_ADDR=http://vault:8200VAULT_TOKEN=rootSUPERSECRETMESSAGE_HTTP_BINDING_ADDRESS=:80SUPERSECRETMESSAGE_HTTPS_BINDING_ADDRESS=:443SUPERSECRETMESSAGE_HTTPS_REDIRECT_ENABLED=trueSUPERSECRETMESSAGE_TLS_AUTO_DOMAIN=secrets.example.com
Manual TLS
VAULT_ADDR=http://vault:8200VAULT_TOKEN=rootSUPERSECRETMESSAGE_HTTPS_BINDING_ADDRESS=:443SUPERSECRETMESSAGE_TLS_CERT_FILEPATH=/mnt/ssl/cert_secrets.example.com.pemSUPERSECRETMESSAGE_TLS_CERT_KEY_FILEPATH=/mnt/ssl/key_secrets.example.com.pem

Screenshot

supersecretmsg

Contributing

Pull requests are very welcome!Please consider that they will be reviewed by our team at Algolia.

Thanks

This project is heavaily depandent on the amazing work of theEcho Go Web Framework and Hashicorp Vault.

This project is certified Awesome F/OSS

About

Simple to use, simple to deploy, one time self destruct messaging service, with hashicorp vault as a backend

Topics

Resources

License

Code of conduct

Stars

Watchers

Forks

Packages

No packages published

Contributors21


[8]ページ先頭

©2009-2025 Movatter.jp