ArangoDB v4.x is under development and not released yet.
This documentation is not final and potentially incomplete.
Audit logging and encryption HTTP APIs
The security-related endpoints in the HTTP interface let you inspect and reload the TLS data, and inspect and rotate the encryption at rest keys
Audit logging
You can get and set the log level for the audit-* log topics using the regular
endpoints for the log levels. See Logs.
The audit logging feature can otherwise only be configured using startup options. See Audit logging.
Encryption in transit
Get the TLS data
Return a summary of the TLS data. The JSON response will contain a field
result with the following components:
keyfile: Information about the key file.clientCA: Information about the Certificate Authority (CA) for client certificate verification.
If server name indication (SNI) is used and multiple key files are
configured for different server names, then there is an additional
attribute SNI, which contains for each configured server name
the corresponding information about the key file for that server name.
In all cases the value of the attribute will be a JSON object, which has a subset of the following attributes (whatever is appropriate):
sha256: The value is a string with the SHA256 of the whole input file.certificates: The value is a JSON array with the public certificates in the chain in the file.privateKeySha256: In cases where there is a private key (keyfilebut notclientCA), this field is present and contains a JSON string with the SHA256 of the private key.
This API requires authentication.
Reload the TLS data
This API call triggers a reload of all the TLS data (server key, client-auth CA) and then returns a summary. The JSON response is exactly as in the corresponding GET request.
This endpoint requires a
superuser JWT. User accounts,
including root, are not sufficient.
Encryption at rest
Get the encryption at rest key hashes
Get information about the currently loaded user-supplied encryption at
rest keys. The keys themselves are not returned, only the SHA-256 hashes
of the key secrets. If you use the
--rocksdb.encryption-keyfolder
startup option, there is one entry for every key file in the folder.
This endpoint is only available if the
--rocksdb.encryption-key-rotation startup option
is enabled.
This API is not available on Coordinator nodes.
Rotate the encryption at rest key
Change the user-supplied encryption at rest key by sending a request without payload to this endpoint. The user key is read again from the configured key source, and the internal encryption key is re-encrypted with it. The stored data itself is not re-encrypted.
You can rotate the key no matter which of the following mutually exclusive startup options you use for supplying the user key:
--rocksdb.encryption-keyfile: The file is read again. It needs to contain the new key when you call this endpoint.--rocksdb.encryption-key-generator: The program is run again. It needs to output the new key.--rocksdb.encryption-keyfolder: All key files in the folder are read again, and the internal encryption key is re-encrypted with every one of these keys. Keys that you removed from the folder can no longer unlock the internal encryption key.
A key folder lets you roll out a new key without downtime because any one of the keys it contains can unlock the internal encryption key. See Rotating encryption keys for the recommended procedure.
Rotating the encryption key is only allowed if the
--rocksdb.encryption-key-rotation startup option
is enabled.
This endpoint requires a
superuser JWT. User accounts,
including root, are not sufficient.
This API is not available on Coordinator nodes.
