a3dfde5cec
* conversion stage 1 * correct image paths * add sidebar title to frontmatter * docs/concepts and docs/internals * configuration docs and multi-level nav corrections * commands docs, index file corrections, small item nav correction * secrets converted * auth * add enterprise and agent docs * add extra dividers * secret section, wip * correct sidebar nav title in front matter for apu section, start working on api items * auth and backend, a couple directory structure fixes * remove old docs * intro side nav converted * reset sidebar styles, add hashi-global-styles * basic styling for nav sidebar * folder collapse functionality * patch up border length on last list item * wip restructure for content component * taking middleman hacking to the extreme, but its working * small css fix * add new mega nav * fix a small mistake from the rebase * fix a content resolution issue with middleman * title a couple missing docs pages * update deps, remove temporary markup * community page * footer to layout, community page css adjustments * wip downloads page * deps updated, downloads page ready * fix community page * homepage progress * add components, adjust spacing * docs and api landing pages * a bunch of fixes, add docs and api landing pages * update deps, add deploy scripts * add readme note * update deploy command * overview page, index title * Update doc fields Note this still requires the link fields to be populated -- this is solely related to copy on the description fields * Update api_basic_categories.yml Updated API category descriptions. Like the document descriptions you'll still need to update the link headers to the proper target pages. * Add bottom hero, adjust CSS, responsive friendly * Add mega nav title * homepage adjustments, asset boosts * small fixes * docs page styling fixes * meganav title * some category link corrections * Update API categories page updated to reflect the second level headings for api categories * Update docs_detailed_categories.yml Updated to represent the existing docs structure * Update docs_detailed_categories.yml * docs page data fix, extra operator page remove * api data fix * fix makefile * update deps, add product subnav to docs and api landing pages * Rearrange non-hands-on guides to _docs_ Since there is no place for these on learn.hashicorp, we'll put them under _docs_. * WIP Redirects for guides to docs * content and component updates * font weight hotfix, redirects * fix guides and intro sidenavs * fix some redirects * small style tweaks * Redirects to learn and internally to docs * Remove redirect to `/vault` * Remove `.html` from destination on redirects * fix incorrect index redirect * final touchups * address feedback from michell for makefile and product downloads
105 lines
4.1 KiB
Markdown
105 lines
4.1 KiB
Markdown
---
|
|
layout: "docs"
|
|
page_title: "Cassandra - Secrets Engines"
|
|
sidebar_title: "Cassandra <sup>DEPRECATED</sup>"
|
|
sidebar_current: "docs-secrets-cassandra"
|
|
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.html).
|
|
|
|
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.
|
|
|
|
```text
|
|
$ 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:
|
|
|
|
```text
|
|
$ 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:
|
|
|
|
```text
|
|
$ 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!
|
|
|
|
```text
|
|
$ 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/index.html) for more
|
|
details.
|