b76a56d40c
* migrates nav data format and updates docs pages * removes sidebar_title from content files
104 lines
4.1 KiB
Plaintext
104 lines
4.1 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Cassandra - Secrets Engines
|
|
description: >-
|
|
The Cassandra secrets engine for Vault generates database credentials to
|
|
access Cassandra.
|
|
---
|
|
|
|
# Cassandra Secrets Engine
|
|
|
|
~> **Deprecation Note:** This secrets engine is deprecated in favor of the
|
|
combined databases secrets engine added in v0.7.1. See the documentation for
|
|
the new implementation of this secrets engine at
|
|
[Cassandra database plugin](/docs/secrets/databases/cassandra).
|
|
|
|
The Cassandra secrets engine for Vault generates database credentials
|
|
dynamically based on configured roles. This means that services that need
|
|
to access a database no longer need to hardcode credentials: they can request
|
|
them from Vault, and use Vault's leasing mechanism to more easily roll keys.
|
|
|
|
Additionally, it introduces a new ability: with every service accessing
|
|
the database with unique credentials, it makes auditing much easier when
|
|
questionable data access is discovered: you can track it down to the specific
|
|
instance of a service based on the Cassandra username.
|
|
|
|
This page will show a quick start for this secrets engine. For detailed documentation
|
|
on every path, use `vault path-help` after mounting the secrets engine.
|
|
|
|
## Quick Start
|
|
|
|
The first step to using the Cassandra secrets engine is to mount it. Unlike the
|
|
`kv` secrets engine, the `cassandra` secrets engine is not mounted by default.
|
|
|
|
```shell-session
|
|
$ vault secrets enable cassandra
|
|
Success! Enabled the cassandra secrets engine at: cassandra/
|
|
```
|
|
|
|
Next, Vault must be configured to connect to Cassandra. This is done by
|
|
writing one or more hosts, a username, and a password:
|
|
|
|
```shell-session
|
|
$ vault write cassandra/config/connection \
|
|
hosts=localhost \
|
|
username=cassandra \
|
|
password=cassandra
|
|
```
|
|
|
|
In this case, we've configured Vault with the user "cassandra" and password "cassandra",
|
|
It is important that the Vault user is a superuser, in order to manage other user accounts.
|
|
|
|
The next step is to configure a role. A role is a logical name that maps
|
|
to a policy used to generated those credentials. For example, lets create
|
|
a "readonly" role:
|
|
|
|
```shell-session
|
|
$ vault write cassandra/roles/readonly \
|
|
creation_cql="CREATE USER '{{username}}' WITH PASSWORD '{{password}}' NOSUPERUSER; \
|
|
GRANT SELECT ON ALL KEYSPACES TO {{username}};"
|
|
Success! Data written to: cassandra/roles/readonly
|
|
```
|
|
|
|
By writing to the `roles/readonly` path we are defining the `readonly` role.
|
|
This role will be created by evaluating the given `creation_cql` statements. By
|
|
default, the `{{username}}` and `{{password}}` fields will be populated by
|
|
Vault with dynamically generated values. This CQL statement is creating
|
|
the named user, and then granting it `SELECT` or read-only privileges
|
|
to keyspaces. More complex `GRANT` queries can be used to
|
|
customize the privileges of the role. See the [CQL Reference Manual](https://docs.datastax.com/en/cql/3.1/cql/cql_reference/grant_r.html)
|
|
for more information.
|
|
|
|
To generate a new set of credentials, we simply read from that role:
|
|
Vault is now configured to create and manage credentials for Cassandra!
|
|
|
|
```shell-session
|
|
$ vault read cassandra/creds/readonly
|
|
Key Value
|
|
--- -----
|
|
lease_id cassandra/creds/test/7a23e890-3a26-531d-529b-92d18d1fa63f
|
|
lease_duration 3600
|
|
lease_renewable true
|
|
password dfa80eea-ccbe-b228-ebf7-e2f62b245e71
|
|
username vault-root-1434647667-9313
|
|
```
|
|
|
|
By reading from the `creds/readonly` path, Vault has generated a new
|
|
set of credentials using the `readonly` role configuration. Here we
|
|
see the dynamically generated username and password, along with a one
|
|
hour lease.
|
|
|
|
Using ACLs, it is possible to restrict using the `cassandra` secrets engine such
|
|
that trusted operators can manage the role definitions, and both
|
|
users and applications are restricted in the credentials they are
|
|
allowed to read.
|
|
|
|
If you get stuck at any time, simply run `vault path-help cassandra` or with a
|
|
subpath for interactive help output.
|
|
|
|
## API
|
|
|
|
The Cassandra secrets engine has a full HTTP API. Please see the
|
|
[Cassandra secrets engine API](/api/secret/cassandra) for more
|
|
details.
|