Security
This chapter discusses various security aspects of Stretchy like secret handling, as well as potential risks to be aware of when operating Stretchy.
Secrets
Secrets (keys and passwords that are required to communicate with job sources) are stored unencrypted.
To store them encrypted at rest, encrypt your database. Please consult the documentation of your database on how to do so.
| We are not against encrypting secrets. We would certainly feel better if they were. However, Stretchy Orchestrator has to decrypt them without user involvement to perform its work. Any solution to encrypt secrets has to provide substantial security benefits that at least balance the added complexity. |
Authentication
Passwords are hashed with bcrypt and should only be recoverable with unreasonable effort.
Stretchy Orchestrator’s built-in user database does not support multifactor authentication. We have no plans to change that. For elevated security, we recommend connecting an external identity provider like Keycloak and disabling all users in the built-in database.
If you delete the built-in user with the name admin, Stretchy Orchestrator will recreate it after the next restart.
|
Orchestrator
While the Orchestrator is built to be exposed to the internet, we do not recommend doing so. Instead, put it behind a firewall that only allows direct connections from job sources that require it.
| The firewall has to allow HTTP and WebSocket connections. |
All other job sources, users, and agents should connect by using a VPN or similar technologies like Tailscale.
Nodes
Nodes that host containers or virtual machines that run jobs potentially run untrusted code, especially if you use them to run pull requests that can be submitted by anybody.
While the nodes should be reasonably safe thanks to container and virtual machine isolation, their guests can still be used as a staging ground for attacks, to mine cryptocurrencies, or for other nefarious purposes.
At a minimum, you should put the nodes in an isolated network segment and restrict their access to the public internet. For example, in most cases CI jobs only need access to their job source (GitHub, Jenkins, …), central registries (Docker Hub, Maven Central, …), and deployment targets.
Neither nodes nor guests should ever be directly accessible over the public internet. Use VPN or similar technologies if people need to access them.
Provisioners
Many provisioners generate shell commands that run on the host to create guests or run commands on the guests. Those commands might include parts generated by job sources.
Some provisioners use SSH to communicate with guests. They disable host key checking with StrictHostKeyChecking=no on a per-connection basis.