119 lines
4.9 KiB
Markdown
119 lines
4.9 KiB
Markdown
# Sshecret - Simple Secret management using SSH and RSA Keys
|
|
|
|
Managing secrets within a container environment or homelab can be quite complex.
|
|
|
|
As with container orchestration in general, many of the available tools are targetted large enterprise installations and add significant complexity to both the management of secrets themselves, and to the consumers.
|
|
|
|
For enthusiasts or homelabbers solutions like Hashicorp Vault become overkill
|
|
quickly, and end up consuming a lot more time and energy than what feels
|
|
justified.
|
|
|
|
This system has been created to provide a centralized solution that works well-enough.
|
|
|
|
Sshecret provides a simple, centralized solution for secret storage, and requires only tools that are commonly pre-installed on most linux system.
|
|
|
|
# Concept
|
|
The system uses RSA keys, as generated by openssh, to encrypt secrets for each client.
|
|
|
|
It uses RSA keys as it is possible to do encryption using only the public key.
|
|
|
|
By using a custom SSH server, the consuming servers can fetch a version of a secret encrypted specifically for them.
|
|
|
|
As the secret is encrypted with RSA keys, it can be decrypted using the openssl command which is commonly available.
|
|
|
|
This means that while the backend interface can be complex, the to access and decrypt a secret, you can use ssh, and a simple bash script.
|
|
|
|
# Components
|
|
|
|
There are three components to Sshecret:
|
|
|
|
- Password database and admin interface
|
|
- Client secret storage backend
|
|
- Ssh server for clients to access
|
|
|
|
The three systems should be deployed separately for security, with the backend system as the only central component.
|
|
|
|
The ssh server that the clients connect to, only has access to encrypted versions of the secrets.
|
|
|
|
If it or the backend should be compromised, it wouldn't be possible to extract any clear-text secrets, since only encrypted values are stored, and each encrypted with RSA public key encryption.
|
|
|
|
## Backend
|
|
The backend system stores the definition of each client, including their public key, and the IP addresses/networks they are allowed to connect from.
|
|
It also stores a version of each secret that the client has access to, encrypted with the public key. It has no knowledge of the unencrypted secrets.
|
|
|
|
Both the admin interface and the ssh server access this system over a REST API using a token-based authentication method.
|
|
|
|
## Password database and admin interface
|
|
The sshecret password database is based on keepass, and the admin interface is available as a simple web interface as well as a REST API.
|
|
|
|
This component is primarily responsible for storing the secrets in a keepass database and populating the backend with client-specific encrypted versions.
|
|
|
|
The admin interface must be secured. It currently supports local user accounts, but will be expanded with OIDC support in the near future.
|
|
|
|
## Custom SSH server
|
|
To make it easy to fetch secrets sshecret includes a SSH server.
|
|
|
|
To fetch a secret, simply ssh to it using the client name as username and the
|
|
registered RSA key as authorization.
|
|
|
|
Send the command `get_secret` followed by the name of the secret. The ssh server
|
|
will check the client's public key against permitted keys, and check if the
|
|
client is allowed to connect and if the secret is available to it.
|
|
|
|
The server will answer with a base64 encoded version of the secret.
|
|
|
|
See `examples/sshecret-client.bash` for an example of a bash script that can be
|
|
used to fetch and decrypt a secret.
|
|
|
|
Out of the box, only the `get_secret` command is available, however an optional
|
|
command `register` can be enabled to allow registration of a client using the
|
|
SSH interface to make it easy to onboard new clients automatically.
|
|
|
|
# Configuration
|
|
|
|
Each subsystem is set up using environment variables.
|
|
|
|
## Backend
|
|
The location and type of database may be configured.
|
|
For now, only sqlite is officially supported.
|
|
|
|
The value shown below is the default value. In a docker setup, you may want to
|
|
create a volume and configure this to a path within the volume to be able to
|
|
perform backups.
|
|
|
|
SSHECRET_BACKEND_DATABASE=/path/to/sshecret.db
|
|
|
|
|
|
While the backend can be placed behind reverse proxy and served with HTTPS, it's
|
|
probably better to have keep it inside an internal container network.
|
|
|
|
## Admin
|
|
The backend must be generated on the backend before setting up the admin.
|
|
|
|
SSHECRET_BACKEND_URL=http://backend:8022
|
|
SSHECRET_ADMIN_BACKEND_TOKEN: mySuperSecretBackendToken
|
|
|
|
|
|
## Deployment
|
|
|
|
The system can be deplyed using docker or any other container runtime.
|
|
|
|
See the examples in the `docker/` folder.
|
|
|
|
|
|
# FAQ
|
|
## Why not use Age?
|
|
|
|
I like age a lot, and it's ability to use more ssh key types is certainly a
|
|
winner feature. However, a clear goal of this project is to be able to construct
|
|
a client with minimal dependencies.
|
|
|
|
Using just RSA keys, you can construct a client using only the following tools:
|
|
- base64
|
|
- openssl
|
|
- ssh
|
|
|
|
This means that you can create a client using just a shell script.
|
|
|
|
If age were to be used, the age tool would have to be installed on each client sytem.
|