https://github.com/fossable/sandpolis
Virtual estate monitoring & management!
https://github.com/fossable/sandpolis
administration automation cloud-native cross-platform devops free-software monitoring remote rmm
Last synced: about 2 months ago
JSON representation
Virtual estate monitoring & management!
- Host: GitHub
- URL: https://github.com/fossable/sandpolis
- Owner: fossable
- License: agpl-3.0
- Created: 2017-08-11T20:55:30.000Z (almost 8 years ago)
- Default Branch: master
- Last Pushed: 2025-03-24T19:43:33.000Z (2 months ago)
- Last Synced: 2025-03-29T23:07:36.726Z (2 months ago)
- Topics: administration, automation, cloud-native, cross-platform, devops, free-software, monitoring, remote, rmm
- Language: Rust
- Homepage:
- Size: 16.2 MB
- Stars: 53
- Watchers: 4
- Forks: 8
- Open Issues: 5
-
Metadata Files:
- Readme: README.md
- License: LICENSE.txt
Awesome Lists containing this project
README
`sandpolis` is a **virtual estate monitoring/management tool** (VEM²) under
active development.
## Virtual estate
Virtual/digital estate is an all-encompassing term that generally refers to all
of the (non-physical) assets in your possession. Some of them may be entirely
virtual, like accounts on _github.com_. Others have a physical component as
well, like a server in your closet, Raspberry Pi, or laptop.
All of these entities are part of your _virtual estate_ and are often
intricately connected in various ways. As an example, you might have an SSH key
or API token on your machine that grants access to repositories (a kind of
digital asset) on Github. And suppose your machine also has an authorized key
installed that allows access from another machine:
```
┌──────────┐ SSH Key ┌──────────┐ API Token ┌───────────────────┐
│Machine A ┼───────────►Machine B ┼─────────────► Github │
└──────────┘ └──────────┘ │ │
│ - Private repos │
└───────────────────┘
```
If you care about those repos, then Sandpolis can map out an attack surface that
includes both `Machine A` and `Machine B`. If `Machine A` happens to have a weak
password or one that's shared with another website, then the attack surface is
consequently expanded with appropriate probabilities.
Mapping these relationships automatically is possible because Sandpolis runs an
agent on `Machine A` and `Machine B` (and has API access to Github).
## Security Warning
Sandpolis is an extremely high-value attack target as it provides management
access to your virtual estate. To compensate, strong security measures are
available:
- All connections to a server use mTLS and require a valid client certificate.
The server automatically rotates these certificates periodically, but the
initial certificate must be installed out-of-band.
- Users can be required to login with two-factor authentication codes.
- User permissions restrict what users are able to do and on what instances.
Even with several layers of strong authentication, there's always risk that the
Sandpolis server can be compromised. If the risks of introducing a "single point
of compromise" outweigh the convenience of having a unified management
interface, then **don't use Sandpolis**.
You can choose how much trust you allocate to the Sandpolis network. For
example, agents can optionally run in _read only_ mode which still provides
useful monitoring information, but prohibits all write operations (including
agent updates). This can significantly mitigate potential damage in the event of
server compromise.
## Layers
Features are organized into _layers_ that can be toggled on/off in the UI. If
you build Sandpolis from source, it's also easy to pick and choose what layers
are included:
```sh
# Build the Sandpolis server with remote desktop capabilities ONLY
cargo build --no-default-features --features server --features layer-desktop
```
### Account
Models online/offline accounts and their relationships to agent instances.
Enables higher-order analysis of virtual estate like attack surface mapping and
compromise tracing.
### Alert
Triggers user notifications when certain events are detected in the Sandpolis
network. For example, if a user's status is currently _AWAY_, an unexpected SSH
login from that user (anywhere in the network) will fire an urgent alert.
### Desktop
Provides access to remote desktop capabilities.
### Filesystem
Provides read/write access to agent filesystems. The Sandpolis client can also
mount an agent's filesystem.
### Logging
### Package
Integrates with package managers to monitor package versions.
### Probe
Probes are managable from the Sandpolis network, but don't run agent software.
Instead, a remote Sandpolis agent instance connects to probes over a standard
protocol like SSH, SNMP, Docker, etc.
You can interact with probes almost as if they were regular agents (as long as
the gateway instance remains online).
### Shell
Provides an interactive remote shell.
### Tunnel
### User
## Installation
Crates.io
#### Install from crates.io
```sh
cargo install sandpolis
```
Docker
#### Install server from DockerHub
```yml
# Docker compose
services:
sandpolis-server:
image: sandpolis/server
restart: unless-stopped
```
#### Install client from DockerHub
```sh
alias sandpolis-client="docker run --rm sandpolis/client"
```