Настройка и использование

В этом документе приводится краткий обзор настройки и использования механизма секретов PKI.

1. Настройка

Большинство механизмов секретов должны быть предварительно настроены, прежде чем они смогут выполнять свои функции. Эти шаги обычно выполняются оператором или инструментом управления конфигурацией.

Включите механизм секретов PKI:
```
$ starvault secrets enable pki
Success! Enabled the pki secrets engine at: pki/
```
По умолчанию механизм секретов будет монтироваться по имени механизма. Чтобы подключить механизм секретов по другому пути, используйте аргумент -path.
Увеличьте TTL, настроив параметры механизма секретов. Значение по умолчанию 30 дней может быть слишком коротким, поэтому увеличьте его до 1 года:
```
$ starvault secrets tune -max-lease-ttl=8760h pki
Success! Tuned the secrets engine at: pki/
```
Обратите внимание, что отдельные роли могут ограничить это значение для каждого сертификата. Это настраивает глобальный максимум для данного механизма секретов.

Настройте сертификат CA и закрытый ключ. StarVault может принять существующую пару ключей или сгенерировать собственный root сертификат. В общем случае мы рекомендуем поддерживать root CA вне StarVault и предоставлять StarVault подписанный промежуточный CA.

$ starvault write pki/root/generate/internal \
    common_name=my-website.com \
    ttl=8760h

**Вывод:**
Key	Value
---	----
certificate	-----BEGIN CERTIFICATE-----…
expiration	1536807433
issuing_ca	-----BEGIN CERTIFICATE-----…
serial_number	7c:f1:fb:2c:6e:4d:99:0e:82:1b:08:0a:81:ed:61:3e:1d:fa:f5:29

Возвращаемый сертификат носит исключительно информационный характер. Закрытый ключ надежно хранится внутри StarVault.

Обновление местоположения CRL и сертификатов выпуска. Эти значения могут быть обновлены в будущем.

$ starvault write pki/config/urls \
    issuing_certificates="http://127.0.0.1:8200/v1/pki/ca" \
    crl_distribution_points="http://127.0.0.1:8200/v1/pki/crl"
Success! Data written to: pki/config/urls

Настройте роль, связывающая имя в StarVault с процедурой генерации сертификатов. Когда пользователи или машины генерируют учетные данные, они генерируются в соответствии с этой ролью:
```
$ starvault write pki/roles/example-dot-com \
    allowed_domains=my-website.com \
    allow_subdomains=true \
    max_ttl=72h
Success! Data written to: pki/roles/example-dot-com
```

2. Использование

После того как механизм секретов настроен и у пользователя/машины есть токен StarVault с соответствующими правами, он может генерировать учетные данные.

Сгенерируйте новые учетные данные, записав в конечную точку /issue имя роли:

$ starvault write pki/issue/example-dot-com \
    common_name=www.my-website.com

**Вывод:**
Key	Value
---	----
certificate	-----BEGIN CERTIFICATE-----…
issuing_ca	-----BEGIN CERTIFICATE-----…
private_key	-----BEGIN RSA PRIVATE KEY-----…
private_key_type	rsa
serial_number	1d:2e:c6:06:45:18:60:0e:23:d6:c5:17:43:c0:fe:46:ed:d1:50:be

На выходе мы получим динамически сгенерированный закрытый ключ и сертификат, который соответствует заданной роли и истекает через 72 часа (как диктует наше определение роли). Для простоты автоматизации также возвращается CA выдачи и цепочка доверия.

3. API

Движок секретов PKI имеет полный HTTP API. Более подробная информация приведена в разделе API движка PKI secrets.