<commit_before># Securing rqlite
rqlite can be secured in various way, and at different levels of control.

## File system security
You are responsible for securing access to the SQLite databases. There is no reason for any user to directly access the SQLite file, for rqlite to work correctly.

## Network security
Each rqlite node listens on 2 TCP ports -- one for the HTTP API, and the other for intra-cluster communications. Only the API port need be reachable from outside the cluster.

So, if possible, configure the network such that the Raft port on each node is only accessible from other nodes in the cluster. There is no need for the Raft port to be accessible by rqlite clients.

If the IP addresses (or subnets) of rqlite clients is also known, it may also be possible to limit access to the HTTP API from those addresses only.

AWS EC2 [Security Groups](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html), for example, support all this functionality. So if running rqlite in the AWS EC2 cloud you can implement this level of security at the network level.

## HTTPS API
rqlite supports HTTPS access, ensuring that all communication between clients and a cluster is encrypted.

## Basic Auth
The HTTP API supports [Basic Auth](https://tools.ietf.org/html/rfc2617). Each rqlite node can be passed a JSON-formatted configuration file, which configures valid usernames and associated passwords for that node.

Since the configuration file only controls the node local to it, it's important to ensure the configuration is correct on each node.

### User-level permissions
rqlite, via the configuration file, also supports user-level permissions. Each user can be granted one or more of the following permissions:
- _all_: user can perform all operations on a node.
- _execute_: user may access the execute endpoint.
- _query_: user may access the query endpoint.
- _backup_: user may perform backups.
- _status_: user can retrieve status information from the node.
- _join_: user can join a cluster. In practice only a node joins a cluster.
- _remove_: user can remove a node from a cluster.

### Example configuration file
An example configuration file is shown below.
```json<commit_msg>Update SECURITY.md<commit_after># Securing rqlite
rqlite can be secured in various way, and at different levels of control.

## File system security
You are responsible for securing access to the SQLite database file if you don't use in-memory databases. There is no reason for any user to directly access any SQLite file, for rqlite to work correctly.

## Network security
Each rqlite node listens on 2 TCP ports -- one for the HTTP API, and the other for intra-cluster communications. Only the API port need be reachable from outside the cluster.

So, if possible, configure the network such that the Raft port on each node is only accessible from other nodes in the cluster. There is no need for the Raft port to be accessible by rqlite clients.

If the IP addresses (or subnets) of rqlite clients is also known, it may also be possible to limit access to the HTTP API from those addresses only.

AWS EC2 [Security Groups](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html), for example, support all this functionality. So if running rqlite in the AWS EC2 cloud you can implement this level of security at the network level.

## HTTPS API
rqlite supports HTTPS access, ensuring that all communication between clients and a cluster is encrypted.

## Basic Auth
The HTTP API supports [Basic Auth](https://tools.ietf.org/html/rfc2617). Each rqlite node can be passed a JSON-formatted configuration file, which configures valid usernames and associated passwords for that node.

Since the configuration file only controls the node local to it, it's important to ensure the configuration is correct on each node.

### User-level permissions
rqlite, via the configuration file, also supports user-level permissions. Each user can be granted one or more of the following permissions:
- _all_: user can perform all operations on a node.
- _execute_: user may access the execute endpoint.
- _query_: user may access the query endpoint.
- _backup_: user may perform backups.
- _status_: user can retrieve status information from the node.
- _join_: user can join a cluster. In practice only a node joins a cluster.
- _remove_: user can remove a node from a cluster.

### Example configuration file
An example configuration file is shown below.
```json
{'fraction_non_alphanumeric': 0.049555555555555554, 'fraction_numerical': 0.0035555555555555557, 'mean_word_length': 4.3775388291517325, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2172439', 'n_tokens_mistral': 1135, 'n_tokens_neox': 1093, 'n_words': 677}