thebestvibedev/tromcho.net
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add detailed security feature documentation

Browse Source
This commit is contained in:
Vitaliy Filippov
2026-07-08 01:02:30 +03:00
parent 2e03568225
commit 5c0bf7c293
4 changed files with 1332 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/intro/quickstart.en.md
+6 -2
View File
@@ -41,12 +41,16 @@
## Configure monitors
On the monitor hosts:
- Put identical etcd_address into `/etc/vitastor/vitastor.conf`. Example:
- Create minimal configuration in `/etc/vitastor/vitastor.conf`:
```
{
"etcd_address": ["10.200.1.10:2379","10.200.1.11:2379","10.200.1.12:2379"]
"etcd_address": ["http://10.200.1.10:2379","http://10.200.1.11:2379","http://10.200.1.12:2379"],
"osd_network": "10.200.1.0/24",
"use_perms": false
}
```
- Note that you can enable encryption by using `https://` and `use_perms` option.
[Details](security.en.md#quick-setup) about encryption setup with make-etcd.
- Create systemd units for etcd by running: `/usr/lib/vitastor/mon/make-etcd`
Or, if you installed Vitastor in Docker, run `systemctl start vitastor-host; docker exec vitastor make-etcd`.
- Start etcd and monitors: `systemctl enable --now vitastor-etcd vitastor-mon`
docs/intro/quickstart.ru.md
+7 -9
View File
@@ -41,25 +41,23 @@
## Настройте мониторы
На хостах, выделенных под мониторы:
- Пропишите одинаковые etcd_address в `/etc/vitastor/vitastor.conf`. Например:
- Создайте минимальную конфигурацию в `/etc/vitastor/vitastor.conf`:
```
{
"etcd_address": ["10.200.1.10:2379","10.200.1.11:2379","10.200.1.12:2379"]
"etcd_address": ["http://10.200.1.10:2379","http://10.200.1.11:2379","http://10.200.1.12:2379"],
"osd_network": "10.200.1.0/24",
"use_perms": false
}
```
- Обратите внимание, что с помощью схемы `https://` и опции `use_perms` можно включить шифрование.
[Подробно](security.ru.md#быстрая-настройка) о настройке шифрования через make-etcd.
- Инициализируйте сервисы etcd, запустив `/usr/lib/vitastor/mon/make-etcd`.\
Либо, если вы установили Vitastor в Docker, запустите `systemctl start vitastor-host; docker exec vitastor make-etcd`.
- Запустите etcd и мониторы: `systemctl enable --now vitastor-etcd vitastor-mon`
## Настройте OSD
- Пропишите etcd_address и [osd_network](../config/network.ru.md#osd_network) в `/etc/vitastor/vitastor.conf`. Например:
```
{
"etcd_address": ["10.200.1.10:2379","10.200.1.11:2379","10.200.1.12:2379"],
"osd_network": "10.200.1.0/24"
}
```
- Создайте/скопируйте с узлов с мониторами файл конфигурации `/etc/vitastor/vitastor.conf`.
- Инициализуйте OSD:
- Только SSD или только HDD: `vitastor-disk prepare /dev/sdXXX [/dev/sdYYY ...]`.
Если вы используете десктопные SSD без конденсаторов, добавьте опцию `--disable_data_fsync off`,
docs/intro/security.en.md
+657
View File
@@ -0,0 +1,657 @@
[Documentation](../../README.md#documentation) → Introduction → Security in Vitastor
-----
[Читать на русском](security.ru.md)
# Security in Vitastor
- [Overview](#overview)
- [Quick setup](#quick-setup)
- Principles of operation
- [etcd transport encryption (TLS)](#etcd-transport-encryption-tls)
- [OSD transport encryption (AES-GCM)](#osd-transport-encryption-aes-gcm)
- [End-to-end image data encryption (AES-XTS)](#end-to-end-image-data-encryption-aes-xts)
- [Certificate-based authentication](#certificate-based-authentication)
- [Users and access rights](#users-and-access-rights)
- [etcd privileges](#etcd-privileges)
- Manual setup
- [Configuring OSD transport encryption](#configuring-osd-transport-encryption)
- etcd/Antietcd setup options
- [Mon with embedded Antietcd](#mon-with-embedded-antietcd)
- [Mon as an Etcd proxy](#mon-as-an-etcd-proxy)
- [Mon with a separate Antietcd Proxy](#mon-with-a-separate-antietcd-proxy)
- [Standalone Antietcd without etcd](#standalone-antietcd-without-etcd)
- [Vault/OpenBao setup](#vaultopenbao-setup)
- [Vault setup example](#vault-setup-example)
- Lists of allowed operations
- [etcd data access rights](#etcd-data-access-rights)
- [OSD data access rights](#osd-data-access-rights)
- [API access rights](#api-access-rights)
- [Encryption performance](#encryption-performance)
## Overview
Starting from version 3.1.0, Vitastor provides full data protection:
control plane protection (etcd), data plane protection (OSDs), and end-to-end data encryption.
- Control plane protection:
- etcd transport encryption (TLS)
- Authentication via client TLS (X.509) certificates
- Access control of clients to etcd data
- Data plane protection:
- Full AES-GCM encryption of OSD transport (similar to TLS, but faster)
- Alternatively, AES-GCM encryption of just operation headers with data checksums using a secret "salt"
- Authentication via client TLS (X.509) certificates
- Access control of clients on the OSD side
- End-to-end encryption:
- Data is encrypted using AES-XTS on the client side, the Vitastor cluster has no access to plaintext data
- AES-XTS keys can be stored in etcd or in an external Vault/OpenBao
All features are optional and disabled in the simplest configuration. By default, only
transport-level data checksums ([proto_checksums](../config/security.en.md#proto_checksums)=payload)
are enabled for clients that support them (>= 3.1.0). For older clients, connections
without data checksums are allowed by default ([force_proto_checksums](../config/security.en.md#force_proto_checksums) is empty).
For a quick setup, jump to the [Quick setup](#quick-setup) section.
Descriptions of all security-related parameters can be found [here](../config/security.en.md).
## Quick setup
For a quick setup, use the `/usr/lib/vitastor/mon/make-etcd` script:
1. Log in to the node where the first monitor and etcd will be located.
2. Create `/etc/vitastor/vitastor.conf` with minimal parameters: etcd_address,
osd_network and, if you want to enable privileges, use_perms (note `https://`
in etcd addresses):
```
{
"etcd_address": ["https://10.0.0.10:2379","https://10.0.0.11:2379","https://10.0.0.12:2379"],
"osd_network": "10.0.0.0/24",
"use_perms": true
}
```
3. Run `/usr/lib/vitastor/mon/make-etcd` without parameters or with the `--antietcd-only`
parameter if you want to initialize the cluster with Antietcd only, without etcd.
4. The script will generate all necessary certificates and offer to copy them to the other
monitor nodes (agree!).
5. Log in to all other monitor nodes and repeat the `/usr/lib/vitastor/mon/make-etcd` call there.
6. If you also have nodes with OSDs only (without monitors), run the following command to
copy only the required configuration to these nodes:
```
/usr/lib/vitastor/mon/make-etcd --copy-to-osd osdnode1,osdnode2,...
```
After that, you can proceed with OSD initialization.
If you want to understand the setup in more detail, read the [Principles of operation](#principles-of-operation)
and [Manual setup](#manual-setup) sections below.
## Principles of operation
### etcd transport encryption (TLS)
Possible setups:
- Without encryption (http)
- With encryption (https)
- With encryption and client certificate authentication. Either the same certificate
used for authentication on the OSD side (`cert`+`pkey` / `osd_cert`+`osd_pkey`)
is used, or a separately specified certificate (`etcd_client_cert`+`etcd_client_key`).
### OSD transport encryption (AES-GCM)
Possible setups:
- Unencrypted transport without checksums: `proto_checksums=none`.
- Unencrypted transport with data checksums: `proto_checksums=payload` (may be omitted,
this is the default value). It's allowed to disable checksums on the client side, or
use an older client that does not support checksums. If you want to block connections
from clients without checksums, use the option `force_proto_checksums=payload`.
- Header-only encryption with data checksums: activated when the options
`cert`, `pkey`, `osd_ca` are set on the client side and `osd_cert`, `osd_pkey`, `osd_ca`, `client_ca`
on the OSD side, with `proto_checksums=payload`. In this mode, disabling checksums on the client
side is forbidden by default, i.e. `force_proto_checksums=payload` is used.
- Full transport encryption of all traffic: same as the previous option, but with `proto_checksums=gcm`.
In this case, clients are by default allowed to downgrade to checksums only, but this
can also be forbidden via `force_proto_checksums=gcm`. This is the slowest setup and
it's only recommended for insecure (public) networks. In particular, full traffic
encryption together with end-to-end AES-XTS image encryption encrypts data twice.
Encryption uses the AES-256-GCM algorithm and a custom simplified key exchange protocol,
fully analogous to TLS 1.3 ECDHE.
### End-to-end image data encryption (AES-XTS)
The Vitastor client supports encrypting each image's data with its own key. In this case,
data is encrypted by the client before sending it to OSDs and OSDs can't see it in plain.
The encryption key can be changed when cloning/creating image snapshots. For example,
you can make a base VM image (say, Debian Linux) unencrypted, but have encrypted client VM
images inheriting from it.
Image encryption keys can be stored in etcd or in an external Vault. In the latter case,
etcd only stores key IDs and Vitastor cluster can't decrypt the data at all. To use
Vault, create an image with the `--enc_key vault:ID` option, specify vault_url and vault_ca
options in the configuration, create accounts for all clients in Vault, and grant them access
to the required v1 secrets.
Once again, if AES-XTS is used together with full traffic encryption (`proto_checksums=gcm`),
image data is encrypted twice — first with AES-XTS, and then with AES-GCM. Use it only if
you are completely paranoid :-).
### Certificate-based authentication
When encryption is enabled, Vitastor clients, OSDs, and monitors authenticate via certificates
for both etcd (Antietcd) and OSD connections.
Separate certificates must be used for OSDs and monitors — either self-signed, or signed
by separate CAs (`osd_ca` and `mon_ca`). All OSDs can use the same certificate, and all
monitors can also use the same certificate, since the privileges of different OSDs or
different monitors do not differ (theoretically, one could differentiate OSD certificates
by pool, but there has been no need for this so far).
Also, a monitor certificate may not be needed at all if Antietcd is embedded into the monitor
itself. In this case, the monitor already has access to all etcd data directly in memory.
### Users and access rights
When transport encryption is disabled, Vitastor operates without access control, i.e.,
any cluster client has full access to both the management layer and the data layer. This
option is suitable for dedicated trusted storage networks.
When OSD transport encryption is enabled (at least for headers), you can enable access
rights by turning on the `use_perms=true` option. When this option is enabled, each user
can perform only the operations that they are permitted, and even OSDs and monitors are
also forbidden from performing "unnecessary" operations.
Each user (or administrator) must have their own certificate signed by a common root
certificate for clients (`client_ca`), with a Common Name equal to the user name.
Privilege settings are stored in etcd. OSDs and monitors don't need user accounts;
they authenticate via separate certificates.
User privileges are stored in etcd data under the keys `/vitastor/config/user/<name>`.
The following is defined per user in this key:
- Type:
- Client (`type=client` or omitted) — can only read and modify explicitly permitted images.
- Administrator (`type=admin`) — can read and modify all images, and also administer the
cluster: view overall statistics and status, create and delete OSDs, etc.
- List of group names the user is a member of.
Images have the following properties:
- Owner (owner) — the user name that is allowed to both read and modify the image
- Owner group (owner_group) — the owner group name
- Reader group (reader_group) — the name of the group of users allowed to read the image
And there is also a property on the pool:
- Creator group (creator_group) — the name of the group of users allowed to create images in the pool
For the list of allowed operations on image data on the OSD side, see the
[OSD data access rights](#osd-data-access-rights) section.
### etcd privileges
etcd privileges are implemented through Antietcd in all modes of operation.
Built-in etcd privileges are not supported due to numerous inconveniences:
- Certificate-based authentication does not work at all in etcd's REST interface,
- Privileges are stored separately from k/v data and cannot participate in transactions,
- Only the administrator (root) can change privileges,
- There is no support for filtering range read responses by privileges.
If etcd is used, Antietcd acts as a filtering proxy and can be embedded in the Vitastor
monitor or run separately. In this case, etcd must allow incoming connections only from
Antietcd, and all other components must connect to Antietcd.
If Antietcd runs as a part of the Vitastor monitor, it is sufficient to enable the option
`use_perms=true` and set the required certificates. If Antietcd is run separately, privileges
have to be enabled separately using Antietcd options. For more details on the setup, see
the [etcd/Antietcd setup options](#etcdantietcd-setup-options) section.
For the list of allowed operations with etcd data, see the
[etcd data access rights](#etcd-data-access-rights) section.
## Manual setup
### Configuring OSD transport encryption
You need 2 certificates: one for OSDs and one for signing all client certificates.
For OSDs, you can use a self-signed certificate (osd_ca.crt) or a separate certificate (osd.crt)
signed by a trusted osd_ca.crt certificate. For clients, you must use separate certificates
signed by a common trusted (client_ca.crt).
Add to the Vitastor configuration on OSD servers:
- use_perms: true
- osd_ca: osd_ca.crt
- client_ca: client_ca.crt
- osd_cert: osd_ca.crt
- osd_pkey: osd_ca.key
On the client side:
- use_perms: true
- cert: client.crt
- pkey: client.key
### etcd/Antietcd setup options
The following configuration options are available:
#### Mon with embedded Antietcd
The simplest option. You need 1 certificate for Antietcd (antietcd.crt), plus root
certificates for OSDs and clients.
Vitastor settings (`/etc/vitastor/vitastor.conf`):
- etcd_address: [ "http://mon1:2379", ... ] (addresses of your monitors with port 2379)
- use_perms: true
- use_antietcd: true
- antietcd_cert: antietcd.crt
- antietcd_key: antietcd.key
- etcd_ca: antietcd.crt
- osd_ca: osd_ca.crt
- client_ca: client_ca.crt
#### Mon as an Etcd proxy
If you want to enable privileges, but stay on etcd, you can use etcd proxy mode.
You will need 2 separate certificates: one for etcd (etcd.crt) and one for antietcd (antietcd.crt).
The etcd client port must be different from the standard 2379 — for example, you can pick 2381.
OSD and client certificates are also needed.
Vitastor settings:
- etcd_address: [ "http://mon1:2379", ... ] (addresses of your monitors with port 2379)
- use_perms: true
- use_antietcd: true
- etcd_proxy:
```
{
"urls": [ "http://mon1:2381", ... ], // addresses of your etcd with port 2381
"cert": "antietcd.crt",
"key": "antietcd.key",
"ca": "etcd.crt"
}
```
- antietcd_cert: antietcd.crt
- antietcd_key: antietcd.key
- etcd_ca: antietcd.crt
- osd_ca: osd_ca.crt
- client_ca: client_ca.crt
etcd command-line options:
```
--advertise-client-urls=https://<ADDRESS>:2381 --listen-client-urls=https://<ADDRESS>:2381 \
--client-cert-auth --cert-file=etcd.crt --key-file=etcd.key --trusted-ca-file=antietcd.crt \
--peer-client-cert-auth --peer-cert-file=etcd.crt --peer-key-file=etcd.key --peer-trusted-ca-file=etcd.crt
```
#### Mon with a separate Antietcd Proxy
If in addition to the previous option you want to offload Antietcd from the Vitastor monitor's
tasks, you can run it separately.
Similar to the previous option, 2 certificates are needed: one for etcd and one for antietcd,
plus separate certificates for clients, OSDs, and monitors will be needed.
Vitastor settings:
- etcd_address: [ "http://mon1:2379", ... ] (addresses of your monitors with port 2379)
- use_perms: true
- use_antietcd: false
- etcd_ca: antietcd.crt
- osd_ca: osd_ca.crt
- client_ca: client_ca.crt
- mon_etcd_client_cert: mon_ca.crt
- mon_etcd_client_key: mon_ca.key
Antietcd command-line options:
```
--port 2379 \
--client_cert_auth 1 --auth_filter vitastor_auth_filter.js --etcd_proxy url1,url2,... \
--cert antietcd.crt --key antietcd.key --ca client_ca.crt --osd_ca osd_ca.crt --mon_ca mon_ca.crt \
--etcd_cert antietcd.crt --etcd_key antietcd.key --etcd_ca etcd.crt
```
etcd command-line options (same as in the previous option):
```
--advertise-client-urls=https://<ADDRESS>:2381 --listen-client-urls=https://<ADDRESS>:2381 \
--client-cert-auth --cert-file=etcd.crt --key-file=etcd.key --trusted-ca-file=antietcd.crt \
--peer-client-cert-auth --peer-cert-file=etcd.crt --peer-key-file=etcd.key --peer-trusted-ca-file=etcd.crt
```
#### Standalone Antietcd without etcd
Same as the previous option, but etcd and its certificate are not needed:
Vitastor settings (same as in the previous option):
- etcd_address: [ "http://mon1:2379", ... ] (addresses of your monitors with port 2379)
- use_perms: true
- use_antietcd: false
- etcd_ca: antietcd.crt
- osd_ca: osd_ca.crt
- client_ca: client_ca.crt
- mon_etcd_client_cert: mon_ca.crt
- mon_etcd_client_key: mon_ca.key
Antietcd command-line options:
```
--port 2379 \
--client_cert_auth 1 --auth_filter vitastor_auth_filter.js \
--persist_filter vitastor_persist_filter.js \
--cert antietcd.crt --key antietcd.key --ca client_ca.crt --osd_ca osd_ca.crt --mon_ca mon_ca.crt
```
### Vault/OpenBao setup
To use Vault, each client that needs to get image keys from Vault needs a Vault account.
Vitastor only supports client certificate-based authentication, so all client certificates
(`cert`+`pkey`) must be registered in Vault, and they must be granted access to the
corresponding secrets (v1 secrets API is supported).
The required format of a Vault secret is a single `key` field as a hexadecimal string.
The AES-256-XTS algorithm is used, so the key length is 64 bytes, i.e., the string must
consist of 128 hexadecimal digits.
To connect to Vault, set the following settings in Vitastor.conf:
- `vault_url` — Vault address (e.g., `https://vault:8200`)
- `vault_ca` — Vault's own certificate
After that, if you create an image (`vitastor-cli create`) with the option `--enc_key vault:<ID>`,
Vitastor clients will first contact Vault to obtain a token at `/v1/auth/cert/login`,
and then request the actual secret from Vault at `/v1/secret/<ID>`.
#### Vault setup example
Step-by-step instructions for setting up a test Vault using OpenBao as an example:
1. If TLS is not yet configured, generate a self-signed TLS certificate for Vault:
```
openssl req -days 3650 -x509 -addext basicConstraints=critical,CA:TRUE,pathlen:1 --addext subjectAltName=DNS:vault \
-new -newkey rsa:4096 -nodes -keyout /etc/openbao/vault.key -out /etc/openbao/vault.crt
```
Configure it in `/etc/openbao/openbao.hcl`:
```
listener "tcp" {
address = "0.0.0.0:8200"
tls_cert_file = "/etc/openbao/vault.crt"
tls_key_file = "/etc/openbao/vault.key"
}
```
And restart OpenBao (`systemctl restart openbao`).
2. Copy Vault's TLS certificate for Vitastor:
```
cp /etc/openbao/vault.crt /etc/vitastor/vault.crt
```
Transfer it to all client nodes and specify it in `/etc/vitastor/vitastor.conf`:
```
{
...
"vault_url": "http://vault:8200",
"vault_ca": "/etc/vitastor/vault.crt"
}
```
3. Check Vault status:
```
bao status -ca-cert /etc/openbao/vault.crt -address=https://vault:8200
```
4. Initialize Vault in test mode from 1 node (with 1 key share):
```
bao operator init -n 1 -t 1 -ca-cert /etc/openbao/vault.crt -address=https://vault:8200
```
5. Unseal Vault:
```
bao operator unseal -ca-cert /etc/openbao/vault.crt -address=https://vault:8200
```
6. Enable certificate-based authentication:
```
bao auth enable -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 cert
```
7. Enable v1 secrets:
```
bao secrets enable -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 -path=secret kv-v1
```
8. Create a test secret:
```
bao kv put -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 secret/vitastor/testimg3 key=$(openssl rand -hex 64)
```
9. Generate a signed certificate for a Vitastor user (on a machine where you have `client_ca.crt` and `client_ca.key`):
```
openssl req -subj '/CN=testimg3' -nodes -new -keyout testimg3.key -out testimg3.csr
openssl x509 -req -days 3650 -CA client_ca.crt -CAkey client_ca.key -CAcreateserial -in testimg3.csr -out testimg3.crt
rm testimg3.csr
```
10. Create a user in Vault and grant it access to the secret:
```
cat >testimg3.policy <<EOF
path "/secret/vitastor/testimg3" {
capabilities = ["read"]
}
EOF
bao policy write -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 testimg3 testimg3.policy
bao write -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 auth/cert/certs/testimg3 \
certificate=@testimg3.crt display_name=testimg3 token_ttl=24h token_policies=testimg3
```
11. Test access to the secret:
```
curl --cacert /etc/vitastor/vault.crt --cert testimg3.crt --key testimg3.key \
--json '{}' https://vault:8200/v1/auth/cert/login
```
A token will be printed, substitute it into the following request:
```
curl --cacert /etc/vitastor/vault.crt --cert testimg3.crt --key testimg3.key \
-H 'X-Vault-Token: <RECEIVED TOKEN>' https://vault:8200/v1/secret/vitastor/testimg3
```
12. Create an image in Vitastor with the given secret (as an administrator or someone who
has the right to create images in your pool):
```
vitastor-cli create -s 100G --enc_key vault:vitastor/testimg3 --owner testimg3 testimg3
```
13. Test access to the image as user testimg3:
```
vitastor-cli --cert testimg3.crt --pkey testimg3.key dd if=/dev/urandom oimg=testimg3 bs=1M count=100
```
## Lists of allowed operations
### etcd data access rights
Below, all key names are given without the common prefix `/vitastor`.
Allowed operations with keys in Antietcd for clients (`type=client`):
- Read-only:
- Always allowed:
- `/config/global`
- `/config/node_placement`
- `/config/pools`
- `/pg/config`
- `/osd/state/*`
- `/pg/state/*`
- `/index/maxid/*`
- For images [readable by the user](#users-and-access-rights):
- `/config/inode/*`
- `/index/image/*`
- `/inode/stats/*`
- Read and write:
- For pools in which the user can create images:
- `/index/maxid/*`
- For images owned by the user:
- `/config/inode/*`
- `/index/image/*`
Allowed operations with keys in Antietcd for administrators (`type=admin`):
- Read:
- `/stats`
- `/mon/*`
- `/pg/*`
- `/pgstats/*`
- `/inode/stats/*`
- `/pool/stats/*`
- Read and write:
- `/config/*`
- `/osd/*`
- `/index/*`
- `/pg/history/*`
Allowed operations with keys in etcd for OSDs:
- Read:
- `/pg/config`
- `/config/*`
- Read and write:
- `/osd/*`
- `/pg/state/*`
- `/pg/history/*`
- `/pgstats/*`
Allowed operations with keys in etcd for monitors:
- Read:
- `/config/*`
- `/osd/*`
- `/pgstats/*`
- Read and write:
- `/pg/config`
- `/stats`
- `/history/last_clean_pgs`
- `/mon/*`
- `/pg/history/*`
- `/inode/stats/*`
- `/pool/stats/*`
### OSD data access rights
When the `use_perms` option and encryption are enabled, OSDs authenticate clients via
certificates and allow each client only what is allowed by the access control model.
Client operations:
- READ — allowed for images the user has read access to.
- WRITE, DELETE, SCRUB — allowed for images the user has write access to.
- SYNC — the operation is not tied to an image and is always allowed.
- DESCRIBE — the operation is allowed only for administrators (used by the commands
`vitastor-cli describe` and `fix`).
- PING — the operation is always allowed.
- SHOW_CONFIG — the operation is always allowed, however, if the client presents
itself as an OSD in it, then it is verified that it uses a certificate signed by `osd_ca`.
- SEC_LIST (listing) — allowed for other OSDs and administrators with any parameters,
and for regular clients only allowed for requests limited to an image the user has
read access to.
Cluster operations — allowed only for other OSDs:
- SEC_READ
- SEC_WRITE
- SEC_WRITE_STABLE
- SEC_SYNC
- SEC_STABILIZE
- SEC_ROLLBACK
- SEC_DELETE
- SEC_READ_BMP
- SEC_LOCK
### API access rights
[vitastor-cli serve](../usage/cli.en.md#serve) also supports client authentication
via certificates. Only certificates signed by `client_ca` are accepted. A separate
certificate `server_cert` with the key `server_pkey` is used as the server certificate.
For `vitastor-cli serve` to work correctly, it itself must use a certificate
(`cert`+`pkey`) of a user with administrator rights (`type=admin`) to access Vitastor.
Regular clients, when accessing the API, are only allowed API operations on images
available to them either for reading (for reads) or for writing (for modification).
All other API calls are allowed only for administrators.
List of allowed API operations:
Clients (users with `type=client`) are allowed the following operations:
- image/list — for images the user can read.
- image/create — for pools in which the user is allowed to create images, or for
creating snapshots of images owned by the user.
- image/delete, image/flatten, image/modify — for images owned by the user.
All other operations are allowed only for administrators (`type=admin`).
## Encryption performance
You may wonder — how fast is all this wonderful encryption?
The answer is — it depends heavily on the CPU. On modern processors (with AVX512 with VAES
support) it is very fast — AES encryption speed can reach 10-20 GB/s and above. This
primarily concerns the CPU of client machines, because end-to-end encryption is performed
entirely on the client, and client uses its signle thread for transport encryption too,
while there are many OSDs on the server side, and it is easier to add resources there.
On older processors, the speed is noticeably worse — for example, on a Xeon E5 v4 it is
only 3 GB/s.
You can evaluate the performance of your processors using the `vitastor-cli cpubench` command.
Example output (💪 AMD EPYC 9575F):
```
$ vitastor-cli cpubench
Vitastor transport encryption benchmark (AES-256-GCM, AES-256-XTS and xxhash3)
Warmup...
No transport encryption, data checksums enabled, e2e unencrypted image
xxhash3 1 M block... 209000 iterations in 2001 ms = 104447.78 MB/s
xxhash3 4 K block... 37000000 iterations in 2022 ms = 71479.35 MB/s
Header encryption with payload checksums, e2e unencrypted image
AES-256-GCM encrypt header + xxhash3 1 M block... 210000 iterations in 2015 ms = 104218.36 MB/s
AES-256-GCM encrypt header + xxhash3 4 K block... 26000000 iterations in 2073 ms = 48993.01 MB/s
Full transport encryption, e2e unencrypted image
AES-256-GCM encrypt header and 1 M block... 54000 iterations in 2000 ms = 27000.00 MB/s
AES-256-GCM encrypt header and 4 K block... 11700000 iterations in 2014 ms = 22692.71 MB/s
No transport encryption, no checksums, e2e encrypted image
AES-256-XTS encrypt 1 M block... 50000 iterations in 2039 ms = 24521.82 MB/s
AES-256-XTS encrypt 4 K block... 12600000 iterations in 2009 ms = 24499.13 MB/s
No transport encryption, e2e encrypted image, data checksums enabled
AES-256-XTS encrypt + xxhash3 1 M block... 40000 iterations in 2013 ms = 19870.84 MB/s
AES-256-XTS encrypt + xxhash3 4 K block... 10200000 iterations in 2011 ms = 19812.90 MB/s
Header encryption with payload checksums, e2e encrypted image
AES-256-GCM encrypt header + AES-256-XTS encrypt + xxhash3 1 M block... 40000 iterations in 2014 ms = 19860.97 MB/s
AES-256-GCM encrypt header + AES-256-XTS encrypt + xxhash3 4 K block... 8700000 iterations in 2011 ms = 16899.24 MB/s
Full transport encryption, e2e encrypted image
AES-256-XTS + AES-256-GCM encrypt 1 M block... 26000 iterations in 2062 ms = 12609.12 MB/s
AES-256-XTS + AES-256-GCM encrypt 4 K block... 6300000 iterations in 2006 ms = 12267.88 MB/s
```
And here is Xeon E5-2680v4:
```
$ vitastor-cli cpubench
Vitastor transport encryption benchmark (AES-256-GCM, AES-256-XTS and xxhash3)
Warmup...
No transport encryption, data checksums enabled, e2e unencrypted image
xxhash3 1 M block... 62000 iterations in 2021 ms = 30677.88 MB/s
xxhash3 4 K block... 12400000 iterations in 2006 ms = 24146.31 MB/s
Header encryption with payload checksums, e2e unencrypted image
AES-256-GCM encrypt header + xxhash3 1 M block... 62000 iterations in 2027 ms = 30587.07 MB/s
AES-256-GCM encrypt header + xxhash3 4 K block... 6800000 iterations in 2011 ms = 13208.60 MB/s
Full transport encryption, e2e unencrypted image
AES-256-GCM encrypt header and 1 M block... 7000 iterations in 2317 ms = 3021.15 MB/s
AES-256-GCM encrypt header and 4 K block... 1500000 iterations in 2102 ms = 2787.52 MB/s
No transport encryption, no checksums, e2e encrypted image
AES-256-XTS encrypt 1 M block... 7000 iterations in 2317 ms = 3021.15 MB/s
AES-256-XTS encrypt 4 K block... 1600000 iterations in 2088 ms = 2993.30 MB/s
No transport encryption, e2e encrypted image, data checksums enabled
AES-256-XTS encrypt + xxhash3 1 M block... 6000 iterations in 2188 ms = 2742.23 MB/s
AES-256-XTS encrypt + xxhash3 4 K block... 1400000 iterations in 2053 ms = 2663.78 MB/s
Header encryption with payload checksums, e2e encrypted image
AES-256-GCM encrypt header + AES-256-XTS encrypt + xxhash3 1 M block... 6000 iterations in 2190 ms = 2739.73 MB/s
AES-256-GCM encrypt header + AES-256-XTS encrypt + xxhash3 4 K block... 1300000 iterations in 2101 ms = 2417.00 MB/s
Full transport encryption, e2e encrypted image
AES-256-XTS + AES-256-GCM encrypt 1 M block... 4000 iterations in 2666 ms = 1500.38 MB/s
AES-256-XTS + AES-256-GCM encrypt 4 K block... 800000 iterations in 2113 ms = 1478.94 MB/s
```
docs/intro/security.ru.md
+662
View File
@@ -0,0 +1,662 @@
[Документация](../../README-ru.md#документация) → Введение → Безопасность в Vitastor
-----
[Read in English](security.en.md)
# Безопасность в Vitastor
- [Обзор](#обзор)
- [Быстрая настройка](#быстрая-настройка)
- Принципы работы
- [Шифрование соединений с etcd (TLS)](#шифрование-соединений-с-etcd-tls)
- [Шифрование соединений с OSD (AES-GCM)](#шифрование-соединений-с-osd-aes-gcm)
- [Сквозное шифрование данных образов (AES-XTS)](#сквозное-шифрование-данных-образов-aes-xts)
- [Аутентификация по сертификатам](#аутентификация-по-сертификатам)
- [Пользователи и права доступа](#пользователи-и-права-доступа)
- [Привилегии etcd](#привилегии-etcd)
- Ручная настройка
- [Настройка шифрования соединений OSD](#настройка-шифрования-соединений-osd)
- Варианты настройки etcd/Antietcd
- [Mon со встроенным Antietcd](#mon-со-встроенным-antietcd)
- [Mon в роли Etcd proxy](#mon-в-роли-etcd-proxy)
- [Mon с отдельным Antietcd Proxy](#mon-с-отдельным-antietcd-proxy)
- [Отдельный Antietcd без etcd](#отдельный-antietcd-без-etcd)
- [Настройка Vault/OpenBao](#настройка-vaultopenbao)
- [Пример настройки Vault](#пример-настройки-vault)
- Списки разрешённых операций
- [Права доступа к данным etcd](#права-доступа-к-данным-etcd)
- [Права доступа к данным OSD](#права-доступа-к-данным-osd)
- [Права доступа к API](#права-доступа-к-api)
- [Производительность шифрования](#производительность-шифрования)
## Обзор
Начиная с версии 3.1.0, Vitastor предоставляет полную защиту данных: защиту слоя
управления (etcd), защиту слоя данных (OSD) и сквозное шифрование данных.
- Защита слоя управления:
- Шифрование соединений с etcd (TLS)
- Аутентификация по клиентским TLS (X.509) сертификатам
- Разграничение прав доступа клиентов к данным etcd
- Защита слоя данных:
- Либо полное AES-GCM шифрование соединений с OSD (аналогично TLS, но быстрее)
- Либо шифрование AES-GCM только заголовков команд с контрольными суммами данных с секретной "солью"
- Аутентификация по клиентским TLS (X.509) сертификатам
- Разграничение прав доступа клиентов на стороне OSD
- Сквозное шифрование:
- Данные шифруются AES-XTS на стороне клиента, кластер Vitastor не имеет доступа к открытым данным
- Ключи AES-XTS могут храниться в etcd или во внешнем Vault/OpenBao
Все функции опциональны и в простейшем варианте настройки выключены. По умолчанию включены
только контрольные суммы данных на транспортном уровне ([proto_checksums](../config/security.ru.md#proto_checksums)=payload) для
поддерживающих их клиентов (>= 3.1.0). Для более старых клиентов по умолчанию разрешены
соединения без контрольных сумм данных ([force_proto_checksums](../config/security.ru.md#force_proto_checksums) пусто).
Для быстрой настройки перейдите к разделу [Быстрая настройка](#быстрая-настройка).
Описания всех параметров, связанных с безопасностью, читайте [здесь](../config/security.ru.md).
## Быстрая настройка
Для быстрой настройки используйте скрипт `/usr/lib/vitastor/mon/make-etcd`:
1. Зайдите на узел, на котором будет располагаться первый монитор и etcd.
2. Создайте там минимальный `/etc/vitastor/vitastor.conf` с параметрами etcd_address,
osd_network и, если хотите включить привилегии - use_perms (обратите внимание на `https://`
в адресах etcd):
```
{
"etcd_address": ["https://10.0.0.10:2379","https://10.0.0.11:2379","https://10.0.0.12:2379"],
"osd_network": "10.0.0.0/24",
"use_perms": true
}
```
3. Запустите `/usr/lib/vitastor/mon/make-etcd` без параметров или с параметром `--antietcd-only`,
если хотите инициализировать кластер только с Antietcd без etcd.
4. Скрипт сгенерирует все необходимые сертификаты и предложит скопировать их на остальные узлы
мониторов (соглашайтесь!).
5. Зайдите на все остальные узлы мониторов и повторите там вызов `/usr/lib/vitastor/mon/make-etcd`.
6. Если у вас будут узлы только с OSD без мониторов, выполните следующую команду, чтобы скопировать
только нужную конфигурацию на эти узлы:
```
/usr/lib/vitastor/mon/make-etcd --copy-to-osd osdnode1,osdnode2,...
```
После этого можете переходить к инициализации OSD.
Если хотите разобраться в настройке подробнее, читайте далее разделы [Принципы работы](#принципы-работы)
и [Ручная настройка](#ручная-настройка).
## Принципы работы
### Шифрование соединений с etcd (TLS)
Варианты настройки:
- Без шифрования (http)
- С шифрованием (https)
- С шифрованием и аутентификацией по клиентским сертификатам. Используется либо тот
же сертификат, что используется для аутентификации на стороне OSD (`cert`+`pkey` / `osd_cert`+`osd_pkey`),
либо отдельно указанный сертификат (`etcd_client_cert`+`etcd_client_key`)
### Шифрование соединений с OSD (AES-GCM)
Варианты настройки:
- Без шифрования и без контрольных сумм: `proto_checksums=none`.
- Без шифрования, с контрольными суммами данных: `proto_checksums=payload` (можно не указывать,
т.к. это значение по умолчанию). При этом контрольные суммы можно отключить на стороне
клиента либо использовать более старые версии клиента, не поддерживающие контрольные суммы.
Если нужно запретить подключение клиентов без контрольных сумм, можно использовать опцию
`force_proto_checksums=payload`.
- С шифрованием заголовков и контрольными суммами данных: активируется при установленных опциях
`cert`, `pkey`, `osd_ca` на стороне клиента и `osd_cert`, `osd_pkey`, `osd_ca`, `client_ca`
на стороне OSD, при `proto_checksums=payload`. При этом по умолчанию запрещается
отключение контрольных сумм на уровне клиента, то есть используется `force_proto_checksums=payload`.
- С полным шифрованием всего трафика: аналогично прошлому варианту, но с `proto_checksums=gcm`.
Клиенту при этом по умолчанию разрешается понизить уровень защиты до контрольных сумм, но
это тоже можно запретить через `force_proto_checksums=gcm`. Данный вариант самый медленный и
рекомендуется только для небезопасных (публичных) сетей. В том числе потому, что при использовании
и полного шифрования трафика, и сквозного шифрования образов AES-XTS, данные шифруются дважды.
Для шифрования используется алгоритм AES-256-GCM и собственный упрощённый протокол согласования
ключей, полностью аналогичный TLS 1.3 ECDHE.
### Сквозное шифрование данных образов (AES-XTS)
Клиент Vitastor поддерживает шифрование данных каждого образа своим ключом. В этом случае на OSD
уходят уже зашифрованные данные и сами OSD не видят исходные данные клиента. При этом ключ можно
менять при клонировании/создании снимков образов. Например, можно сделать базовый образ ВМ
(условный Debian Linux) нешифрованным, но наследовать от него шифрованные образы клиентских ВМ.
Ключи шифрования образов могут храниться либо в etcd, либо во внешнем Vault. Во втором случае
в etcd хранятся только ID ключей, а Vitastor вообще не имеет доступа к данным образов. Для
использования Vault нужно создать образ с опцией `--enc_key vault:ID`, в конфигурации указать
опции vault_url, и vault_ca, создать всем клиентам учётные записи в Vault и дать им доступ
к требуемым секретам v1.
Ещё раз повторимся, что если AES-XTS используется с полным шифрованием трафика (`proto_checksums=gcm`),
то данные образов шифруются дважды - сначала AES-XTS, а потом AES-GCM. Можете использовать,
только если вы совсем параноик :-).
### Аутентификация по сертификатам
При включённом шифровании клиенты, OSD и мониторы Vitastor аутентифицируются по сертификатам
как при соединениях с etcd (Antietcd), так и с OSD.
Для OSD и мониторов должны использоваться отдельные сертификаты - либо самоподписанные, либо
подписанные отдельными CA (`osd_ca` и `mon_ca`). При этом все OSD могут использовать один и
тот же сертификат и все мониторы тоже могут использовать один и тот же сертификат, так как
привилегии разных OSD или разных мониторов ничем не отличаются (теоретически можно было бы
сделать разграничение сертификатов OSD по пулам, но пока что такой необходимости не было).
Также сертификат монитора может быть вообще не нужен, если Antietcd встраивается в сам монитор.
В этом случае монитор и так имеет доступ ко всем данным etcd прямо в памяти.
### Пользователи и права доступа
При отключённом шифровании трафика Vitastor работает без разграничения прав доступа, то есть,
любой клиент кластера имеет полный доступ как к слою управлению, так и к слою данных. Такой
вариант подходит для выделенных доверенных сетей хранения.
При включённом шифровании трафика OSD (хотя бы заголовков) есть возможность задействовать
права доступа, включив опцию `use_perms=true`. При включённой опции каждый пользователь может
выполнять только те операции, которые ему разрешены, и даже OSD и мониторам также запрещены
"лишние" операции.
Каждый пользователь (или администратор) должен иметь свой сертификат, подписанный общим
корневым сертификатом для клиентов (`client_ca`), с Common Name, равным имени пользователя.
Настройки привилегий же хранятся в etcd. Для OSD и мониторов учётные записи не нужны,
они аутентифицируются по отдельным сертификатам.
Привилегии пользователей хранятся в данных etcd в ключах `/vitastor/config/user/<имя>`.
В этом ключе для каждого пользователя задаётся:
- Тип:
- Клиент (`type=client` или не указано) - может читать и модифицировать только явным образом
разрешённые образы.
- Администратор (`type=admin`) - может читать и модифицировать все образы, а также администрировать
кластер: смотреть общую статистику и состояние, создавать и удалять OSD и так далее.
- Список имён групп, членом которых пользователь является.
У образов есть следующие свойства:
- Владелец (owner) - имя пользователя, которому разрешено и читать, и менять образ
- Группа владельцев (owner_group) - имя группы владельцев
- Группа читателей (reader_group) - имя группы пользователей, которым разрешено читать образ
И также есть свойство у пула:
- Группа создателей (creator_group) - имя группы пользователей, которым разрешено создавать образы в пуле
Перечень разрешённых операций с данными образов на стороне OSD смотрите в разделе
[Права доступа к данным OSD](#права-доступа-к-данным-osd).
### Привилегии etcd
Привилегии etcd реализуются через Antietcd во всех режимах работы.
Встроенные привилегии etcd не поддерживаются по причине их многочисленных неудобств:
- Аутентификация по сертификатам вообще не работает в REST интерфейсе etcd,
- Привилегии хранятся отдельно от k/v данных и не могут участвовать в транзакциях,
- Менять привилегии может только администратор (root),
- Нет поддержки фильтрации диапазонных ответов чтения по привилегиям.
Если используется etcd, то Antietcd выступает в роли фильтрующего прокси, при этом он
может быть встроен в монитор Vitastor или запущен отдельно. В этом случае etcd должен
разрешать входящие подключения только от Antietcd, а все остальные компоненты должны
соединяться с Antietcd.
Если Antietcd запускается в составе монитора Vitastor, то достаточно включить опцию
`use_perms=true` и задать нужные сертификаты. Если Antietcd запускается отдельно, то
привилегии нужно включать отдельно опциями Antietcd. Подробнее о настройке смотрите
раздел [Варианты настройки etcd/Antietcd](#варианты-настройки-etcdantietcd).
Перечень разрешённых операций с данными etcd смотрите в разделе
[Права доступа к данным etcd](#права-доступа-к-данным-etcd).
## Ручная настройка
### Настройка шифрования соединений OSD
Вам нужно 2 сертификата: один для OSD и один для подписи сертификатов всех клиентов.
Для OSD можно использовать самоподписанный сертификат (osd_ca.crt) или отдельный сертификат (osd.crt),
подписанный доверенным сертификатом osd_ca.crt. Для клиентов нужно использовать отдельные
сертификаты, подписанные общим доверенным (client_ca.crt).
В конфигурацию Vitastor на серверах OSD нужно добавить:
- use_perms: true
- osd_ca: osd_ca.crt
- client_ca: client_ca.crt
- osd_cert: osd_ca.crt
- osd_pkey: osd_ca.key
На стороне клиентов:
- use_perms: true
- cert: client.crt
- pkey: client.key
### Варианты настройки etcd/Antietcd
Доступны следующие варианты настройки:
#### Mon со встроенным Antietcd
Самый простой вариант. Вам нужен 1 сертификат для Antietcd (antietcd.crt), плюс
корневые сертификаты для OSD и клиентов.
Настройки Vitastor (`/etc/vitastor/vitastor.conf`):
- etcd_address: [ "http://mon1:2379", ... ] (адреса ваших мониторов с портом 2379)
- use_perms: true
- use_antietcd: true
- antietcd_cert: antietcd.crt
- antietcd_key: antietcd.key
- etcd_ca: antietcd.crt
- osd_ca: osd_ca.crt
- client_ca: client_ca.crt
#### Mon в роли Etcd proxy
Если вы хотите включить привилегии, но остаться на etcd, можно задействовать режим etcd proxy.
Вам понадобится 2 отдельных сертификата: один для etcd (etcd.crt) и один для antietcd (antietcd.crt).
Клиентский порт etcd должен отличаться от стандартного 2379, например, можно выбрать 2381.
Также нужны сертификаты OSD и клиентов.
Настройки Vitastor:
- etcd_address: [ "http://mon1:2379", ... ] (адреса ваших мониторов с портом 2379)
- use_perms: true
- use_antietcd: true
- etcd_proxy:
```
{
"urls": [ "http://mon1:2381", ... ], // адреса ваших etcd с портом 2381
"cert": "antietcd.crt",
"key": "antietcd.key",
"ca": "etcd.crt"
}
```
- antietcd_cert: antietcd.crt
- antietcd_key: antietcd.key
- etcd_ca: antietcd.crt
- osd_ca: osd_ca.crt
- client_ca: client_ca.crt
Опции командной строки etcd:
```
--advertise-client-urls=https://<АДРЕС>:2381 --listen-client-urls=https://<АДРЕС>:2381 \
--client-cert-auth --cert-file=etcd.crt --key-file=etcd.key --trusted-ca-file=antietcd.crt \
--peer-client-cert-auth --peer-cert-file=etcd.crt --peer-key-file=etcd.key --peer-trusted-ca-file=etcd.crt
```
#### Mon с отдельным Antietcd Proxy
Если в дополнение к предыдущему варианту вы хотите разгрузить Antietcd от задач монитора Vitastor,
можно запустить его отдельно.
Аналогично предыдущему варианту нужно 2 сертификата: один для etcd и один для antietcd, плюс понадобятся
отдельные сертификаты для клиентов, OSD и монитора.
Настройки Vitastor:
- etcd_address: [ "http://mon1:2379", ... ] (адреса ваших мониторов с портом 2379)
- use_perms: true
- use_antietcd: false
- etcd_ca: antietcd.crt
- osd_ca: osd_ca.crt
- client_ca: client_ca.crt
- mon_etcd_client_cert: mon_ca.crt
- mon_etcd_client_key: mon_ca.key
Опции командной строки Antietcd:
```
--port 2379 \
--client_cert_auth 1 --auth_filter vitastor_auth_filter.js --etcd_proxy url1,url2,... \
--cert antietcd.crt --key antietcd.key --ca client_ca.crt --osd_ca osd_ca.crt --mon_ca mon_ca.crt \
--etcd_cert antietcd.crt --etcd_key antietcd.key --etcd_ca etcd.crt
```
Опции командной строки etcd (не отличаются от предыдущего варианта):
```
--advertise-client-urls=https://<АДРЕС>:2381 --listen-client-urls=https://<АДРЕС>:2381 \
--client-cert-auth --cert-file=etcd.crt --key-file=etcd.key --trusted-ca-file=antietcd.crt \
--peer-client-cert-auth --peer-cert-file=etcd.crt --peer-key-file=etcd.key --peer-trusted-ca-file=etcd.crt
```
#### Отдельный Antietcd без etcd
Аналогично предыдущему варианту, но etcd и его сертификат не нужны:
Настройки Vitastor (не отличаются от предыдущего варианта):
- etcd_address: [ "http://mon1:2379", ... ] (адреса ваших мониторов с портом 2379)
- use_perms: true
- use_antietcd: false
- etcd_ca: antietcd.crt
- osd_ca: osd_ca.crt
- client_ca: client_ca.crt
- mon_etcd_client_cert: mon_ca.crt
- mon_etcd_client_key: mon_ca.key
Опции командной строки Antietcd:
```
--port 2379 \
--client_cert_auth 1 --auth_filter vitastor_auth_filter.js \
--persist_filter vitastor_persist_filter.js \
--cert antietcd.crt --key antietcd.key --ca client_ca.crt --osd_ca osd_ca.crt --mon_ca mon_ca.crt
```
### Настройка Vault/OpenBao
Для использования Vault каждому клиенту, который будет получать из Vault ключи
образов, нужна учётная запись в Vault. Vitastor поддерживает только аутентификацию
по клиентским сертификатам, так что все сертификаты клиентов (`cert`+`pkey`) должны
быть зарегистрированы в Vault и им должен быть дан доступ к соответствующим секретам
(поддерживается API секретов v1).
Требуемый формат секрета Vault - одно поле `key` в формате шестнадцатеричной строки.
Используется алгоритм AES-256-XTS, так что длина ключа - 64 байта, то есть строка
должна состоять из 128 шестнадцатеричных цифр.
Для подключения Vault включите следующие настройки в Vitastor.conf:
- `vault_url` - адрес Vault (например, `https://vault:8200`)
- `vault_ca` - сертификат самого Vault
После этого, если создать образ (`vitastor-cli create`) с опцией `--enc_key vault:<ID>`,
то для получения ключа клиенты Vitastor сначала обратятся к Vault для получения токена
по адресу `/v1/auth/cert/login`, а потом запросят из Vault сам секрет по адресу `/v1/secret/<ID>`.
#### Пример настройки Vault
Пошаговая инструкция для настройки тестового Vault на примере OpenBao:
1. Если ещё не настроен TLS, генерируем самоподписанный TLS сертификат для Vault:
```
openssl req -days 3650 -x509 -addext basicConstraints=critical,CA:TRUE,pathlen:1 --addext subjectAltName=DNS:vault \
-new -newkey rsa:4096 -nodes -keyout /etc/openbao/vault.key -out /etc/openbao/vault.crt
```
Настраиваем его в `/etc/openbao/openbao.hcl`:
```
listener "tcp" {
address = "0.0.0.0:8200"
tls_cert_file = "/etc/openbao/vault.crt"
tls_key_file = "/etc/openbao/vault.key"
}
```
И перезапускаем OpenBao (`systemctl restart openbao`).
2. Копируем TLS сертификат Vault для Vitastor:
```
cp /etc/openbao/vault.crt /etc/vitastor/vault.crt
```
Переносим его на все клиентские ноды и прописываем в `/etc/vitastor/vitastor.conf`:
```
{
...
"vault_url": "http://vault:8200",
"vault_ca": "/etc/vitastor/vault.crt"
}
```
3. Проверяем статус Vault:
```
bao status -ca-cert /etc/openbao/vault.crt -address=https://vault:8200
```
4. Инициализируем Vault в тестовом режиме из 1 ноды (с 1 частью ключа):
```
bao operator init -n 1 -t 1 -ca-cert /etc/openbao/vault.crt -address=https://vault:8200
```
5. Разблокируем Vault:
```
bao operator unseal -ca-cert /etc/openbao/vault.crt -address=https://vault:8200
```
6. Включаем аутентификацию по сертификатам:
```
bao auth enable -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 cert
```
7. Включаем секреты v1:
```
bao secrets enable -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 -path=secret kv-v1
```
8. Создаём тестовый секрет:
```
bao kv put -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 secret/vitastor/testimg3 key=$(openssl rand -hex 64)
```
9. Генерируем подписанный сертификат для пользователя Vitastor (там, где у вас есть `client_ca.crt` и `client_ca.key`):
```
openssl req -subj '/CN=testimg3' -nodes -new -keyout testimg3.key -out testimg3.csr
openssl x509 -req -days 3650 -CA client_ca.crt -CAkey client_ca.key -CAcreateserial -in testimg3.csr -out testimg3.crt
rm testimg3.csr
```
10. Создаём пользователя в Vault и даём ему доступ к секрету:
```
cat >testimg3.policy <<EOF
path "/secret/vitastor/testimg3" {
capabilities = ["read"]
}
EOF
bao policy write -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 testimg3 testimg3.policy
bao write -ca-cert /etc/openbao/vault.crt -address=https://vault:8200 auth/cert/certs/testimg3 \
certificate=@testimg3.crt display_name=testimg3 token_ttl=24h token_policies=testimg3
```
11. Тестируем доступ к секрету:
```
curl --cacert /etc/vitastor/vault.crt --cert testimg3.crt --key testimg3.key \
--json '{}' https://vault:8200/v1/auth/cert/login
```
Будет выведен токен, подставляем его в следующий запрос:
```
curl --cacert /etc/vitastor/vault.crt --cert testimg3.crt --key testimg3.key \
-H 'X-Vault-Token: <ПОЛУЧЕННЫЙ ТОКЕН>' https://vault:8200/v1/secret/vitastor/testimg3
```
12. Создаём образ в Vitastor с заданным секретом (от имени администратора или того, кто имеет
право создавать образы в вашем пуле):
```
vitastor-cli create -s 100G --enc_key vault:vitastor/testimg3 --owner testimg3 testimg3
```
13. Тестируем доступ к образу от имени пользователя testimg3:
```
vitastor-cli --cert testimg3.crt --pkey testimg3.key dd if=/dev/urandom oimg=testimg3 bs=1M count=100
```
## Списки разрешённых операций
### Права доступа к данным etcd
Ниже все названия ключей приведены без общего префикса `/vitastor`.
Разрешённые операции с ключами в Antietcd для клиентов (`type=client`):
- Только чтение:
- Разрешено всегда:
- `/config/global`
- `/config/node_placement`
- `/config/pools`
- `/pg/config`
- `/osd/state/*`
- `/pg/state/*`
- `/index/maxid/*`
- Для образов, которые [может читать пользователь](#пользователи-и-права-доступа):
- `/config/inode/*`
- `/index/image/*`
- `/inode/stats/*`
- Чтение и запись:
- Для пулов, в которых может создавать образы пользователь:
- `/index/maxid/*`
- Для образов, которыми владеет пользователь:
- `/config/inode/*`
- `/index/image/*`
Разрешённые операции с ключами в Antietcd для администраторов (`type=admin`):
- Чтение:
- `/stats`
- `/mon/*`
- `/pg/*`
- `/pgstats/*`
- `/inode/stats/*`
- `/pool/stats/*`
- Чтение и запись:
- `/config/*`
- `/osd/*`
- `/index/*`
- `/pg/history/*`
Разрешённые операции с ключами в etcd для OSD:
- Чтение:
- `/pg/config`
- `/config/*`
- Чтение и запись:
- `/osd/*`
- `/pg/state/*`
- `/pg/history/*`
- `/pgstats/*`
Разрешённые операции с ключами в etcd для мониторов:
- Чтение:
- `/config/*`
- `/osd/*`
- `/pgstats/*`
- Чтение и запись:
- `/pg/config`
- `/stats`
- `/history/last_clean_pgs`
- `/mon/*`
- `/pg/history/*`
- `/inode/stats/*`
- `/pool/stats/*`
### Права доступа к данным OSD
При включённой опции `use_perms` и шифровании OSD аутентифицирует клиентов по сертификатам
и разрешает каждому клиенту только то, что ему разрешено согласно модели прав доступа.
Клиентские операции:
- READ - разрешено для образов, доступных пользователю на чтение.
- WRITE, DELETE, SCRUB - разрешены для образов, доступных пользователю на запись.
- SYNC - операция не связана с образом и разрешена всегда.
- DESCRIBE - операция разрешена только для администраторов (используются командами
`vitastor-cli describe` и `fix`).
- PING - операция разрешена всегда.
- SHOW_CONFIG - операция разрешена всегда, однако если в ней клиент представляется
как OSD, то проверяется, что он использует сертификат, подписанный `osd_ca`.
- SEC_LIST (листинг) - разрешена другим OSD и администраторам с любыми параметрами,
а обычным клиентам разрешена только для запросов, ограниченных образом, доступным
пользователю на чтение.
Кластерные операции - разрешаются только другим OSD:
- SEC_READ
- SEC_WRITE
- SEC_WRITE_STABLE
- SEC_SYNC
- SEC_STABILIZE
- SEC_ROLLBACK
- SEC_DELETE
- SEC_READ_BMP
- SEC_LOCK
### Права доступа к API
[vitastor-cli serve](../usage/cli.ru.md#serve) также поддерживает клиентскую
аутентификацию по сертификатам. Принимаются только сертификаты, подписанные
`client_ca`. В качестве серверного сертификата используется отдельный сертификат
`server_cert` с ключом `server_pkey`.
При этом для корректной работы `vitastor-cli serve` он сам должен использовать
для доступа в Vitastor сертификат (`cert`+`pkey`) пользователя с правами
администратора (`type=admin`).
Обычным клиентам при доступе к API разрешаются только API-операции с образами,
доступными им либо на чтение (для чтения), либо на запись (для модификации).
Все остальные API-вызовы разрешаются только для администраторов.
Список разрешённых операций API:
Клиентам (пользователям с `type=client`) разрешаются операции:
- image/list - для образов, которые пользователь может читать.
- image/create - для пулов, в которых пользователю разрешено создавать образы, либо
для создания снимков образов, которыми пользователь владеет.
- image/delete, image/flatten, image/modify - для образов, которыми пользователь владеет.
Все остальные операции разрешаются только администраторам (`type=admin`).
## Производительность шифрования
У вас может возникнуть вопрос - а как быстро всё это прекрасное шифрование работает?
Ответ - сильно зависит от процессора. На современных процессорах (при наличии AVX512 с VAES)
очень быстро - скорость шифрования AES может составлять 10-20 Гбайт/с и выше. В первую очередь
подразумевается CPU клиентских машин, потому что сквозное шифрование выполняется целиком на
клиенте, а транспортное хоть также и затрагивает OSD, но у клиента поток один, а OSD на стороне
сервера много и добавить там ресурсов легче.
На более старых процессорах скорость заметно хуже, например, на Xeon E5 v4 она составляет
буквально 3 Гбайт/с.
Вы можете оценить производительность своих процессоров с помощью команды `vitastor-cli cpubench`.
Пример вывода (💪 AMD EPYC 9575F):
```
$ vitastor-cli cpubench
Vitastor transport encryption benchmark (AES-256-GCM, AES-256-XTS and xxhash3)
Warmup...
No transport encryption, data checksums enabled, e2e unencrypted image
xxhash3 1 M block... 209000 iterations in 2001 ms = 104447.78 MB/s
xxhash3 4 K block... 37000000 iterations in 2022 ms = 71479.35 MB/s
Header encryption with payload checksums, e2e unencrypted image
AES-256-GCM encrypt header + xxhash3 1 M block... 210000 iterations in 2015 ms = 104218.36 MB/s
AES-256-GCM encrypt header + xxhash3 4 K block... 26000000 iterations in 2073 ms = 48993.01 MB/s
Full transport encryption, e2e unencrypted image
AES-256-GCM encrypt header and 1 M block... 54000 iterations in 2000 ms = 27000.00 MB/s
AES-256-GCM encrypt header and 4 K block... 11700000 iterations in 2014 ms = 22692.71 MB/s
No transport encryption, no checksums, e2e encrypted image
AES-256-XTS encrypt 1 M block... 50000 iterations in 2039 ms = 24521.82 MB/s
AES-256-XTS encrypt 4 K block... 12600000 iterations in 2009 ms = 24499.13 MB/s
No transport encryption, e2e encrypted image, data checksums enabled
AES-256-XTS encrypt + xxhash3 1 M block... 40000 iterations in 2013 ms = 19870.84 MB/s
AES-256-XTS encrypt + xxhash3 4 K block... 10200000 iterations in 2011 ms = 19812.90 MB/s
Header encryption with payload checksums, e2e encrypted image
AES-256-GCM encrypt header + AES-256-XTS encrypt + xxhash3 1 M block... 40000 iterations in 2014 ms = 19860.97 MB/s
AES-256-GCM encrypt header + AES-256-XTS encrypt + xxhash3 4 K block... 8700000 iterations in 2011 ms = 16899.24 MB/s
Full transport encryption, e2e encrypted image
AES-256-XTS + AES-256-GCM encrypt 1 M block... 26000 iterations in 2062 ms = 12609.12 MB/s
AES-256-XTS + AES-256-GCM encrypt 4 K block... 6300000 iterations in 2006 ms = 12267.88 MB/s
```
А вот Xeon E5-2680v4:
```
$ vitastor-cli cpubench
Vitastor transport encryption benchmark (AES-256-GCM, AES-256-XTS and xxhash3)
Warmup...
No transport encryption, data checksums enabled, e2e unencrypted image
xxhash3 1 M block... 62000 iterations in 2021 ms = 30677.88 MB/s
xxhash3 4 K block... 12400000 iterations in 2006 ms = 24146.31 MB/s
Header encryption with payload checksums, e2e unencrypted image
AES-256-GCM encrypt header + xxhash3 1 M block... 62000 iterations in 2027 ms = 30587.07 MB/s
AES-256-GCM encrypt header + xxhash3 4 K block... 6800000 iterations in 2011 ms = 13208.60 MB/s
Full transport encryption, e2e unencrypted image
AES-256-GCM encrypt header and 1 M block... 7000 iterations in 2317 ms = 3021.15 MB/s
AES-256-GCM encrypt header and 4 K block... 1500000 iterations in 2102 ms = 2787.52 MB/s
No transport encryption, no checksums, e2e encrypted image
AES-256-XTS encrypt 1 M block... 7000 iterations in 2317 ms = 3021.15 MB/s
AES-256-XTS encrypt 4 K block... 1600000 iterations in 2088 ms = 2993.30 MB/s
No transport encryption, e2e encrypted image, data checksums enabled
AES-256-XTS encrypt + xxhash3 1 M block... 6000 iterations in 2188 ms = 2742.23 MB/s
AES-256-XTS encrypt + xxhash3 4 K block... 1400000 iterations in 2053 ms = 2663.78 MB/s
Header encryption with payload checksums, e2e encrypted image
AES-256-GCM encrypt header + AES-256-XTS encrypt + xxhash3 1 M block... 6000 iterations in 2190 ms = 2739.73 MB/s
AES-256-GCM encrypt header + AES-256-XTS encrypt + xxhash3 4 K block... 1300000 iterations in 2101 ms = 2417.00 MB/s
Full transport encryption, e2e encrypted image
AES-256-XTS + AES-256-GCM encrypt 1 M block... 4000 iterations in 2666 ms = 1500.38 MB/s
AES-256-XTS + AES-256-GCM encrypt 4 K block... 800000 iterations in 2113 ms = 1478.94 MB/s
```