Что такое vault плагин

Minecraft: Доступ к API (Vault)

Для работы большинства плагинов в Minecraft, особенно на сервере bukkit нужны специальные библиотеки, о которых знает не так много игроков. Одним из самых нужных плагинов можно считать Vault, потому что без него не будет работать ни одно дополнение для поддержания экономики или расширения прав игроков в определенной группе или сервере. Сюда же относятся и различные дополнения, которые предназначены для введения собственного чата. Причем плагины не зависят друг от друга, и могут работать в полноценной мере поодиночке.

Плагины, поддерживаемые Vault

Здесь перечислим основные дополнения, для которых требуется Vault, а также небольшое описание каждого из них, чтобы вы понимали, для чего они нужны. Основная категория – это плагины для расширения прав игроков. Они позволяют настраивать определенные группы людей и назначать им права, в зависимости от используемых дополнений. Очень полезно на серверах, где есть несколько типов игроков, работает вместе с экономическими плагинами. Сюда относятся такие, как Permissions, PEX, GroupManager и другие. Если дополнению требуется Vault, на сайте в разделе «Установка» будет информация об этом.

Далее в списке идет категория экономических плагинов. Все они предназначены для ведения торгов на сервере при помощи встроенной виртуальной валюты. Обычно такое дополнение после установки автоматически создает новую базу, в которой хранит информацию о денежных переводах каждого игрока. Сюда относятся: iConomy, EconXP – позволяет торговать опытом, MineConomy, eWallet и другие. Для экономики разработано множество дополнений, и практически все они похожи между собой функционалом. И последняя группа – это плагины, которые используются для ведения чата. В игре Minecraft есть встроенный чат, однако он не поддерживает русский язык, и очень часто «тормозит».

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

Установка плагина Vault

Скачайте с сайта Vault, зайдите на свой сервер и перенесите загруженные файлы в папку /plugins, и перезапустите сервер. Обязательно учитывайте версию плагина, и сервера bukkit, который используется на вашем проекте. В настройках дополнения имеется возможность автоматического обновления при наличии новых версий. При желании можно отключить.

Источник

Безопасное использование секретов: шаблон для использования HashiCorp Vault

HashiCorp Vault — это инструмент с открытым исходным кодом, который обеспечивает безопасный и надежный способ хранения и распространения секретов, таких как ключи API, токены доступа и пароли. Программное обеспечение, такое как Vault, может быть критически важным при развертывании приложений, требующих использования секретов или конфиденциальных данных.

Согласно недавнему исследованию ученых из Университета штата Северная Каролина, более 100 000 общедоступных репозиториев GitHub содержат открытые секреты приложений непосредственно в исходном коде. Это исследование — от частных токенов API до криптографических ключей — просканировало только около 13% общедоступных репозиториев GitHub — показывает, что надлежащая защита секретов приложений является одним из наиболее часто игнорируемых методов защиты информации в программном обеспечении.

Хотя масштабы воздействия удивительны, важно отметить, что эта проблема затрагивает не только проекты с открытым исходным кодом. Даже частные репозитории исходного кода могут раскрывать секреты, если они не защищены должным образом. Возьмем, к примеру, нарушение безопасности в Buffer Inc. в 2013 году. То, что начиналось как незаконный доступ к собственному исходному коду Buffer, привело к утечке учетных данных Twitter API компании, что в конечном итоге привело к рассылке спама в учетных записях Twitter бесчисленных клиентов.

Я не собираюсь угнетать Buffer прямо сейчас. Компании взламывают каждый день, и Buffer дал первоклассный ответ. Их нефильтрованная прозрачность и информирование об инцидентах послужили интересным примером важности управления секретами как основного принципа информационной безопасности. Но это также поднимает вопрос о том, как лучше всего управлять секретами в растущей, масштабируемой организации.

Введение в HashiCorp Vault

Я большой поклонник HashiCorp. Их подход к инструментам DevOps, не зависящий от поставщика, предоставляет отличные портативные решения, которые абстрагируются от отдельных поставщиков облачных услуг и фокусируются на решении реальных проблем. Их инструмент управления секретами, Vault, не исключение.

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

Установка Vault

Прежде чем мы сможем начать работу с Vault, нам сначала нужно его установить. Как и все продукты HashiCorp, Vault кроссплатформенный, с поддержкой macOS, Windows, Linux, Solaris и даже BSD. Вы даже можете запустить его на Raspberry Pi.

Запуск сервера

После установки Vault нам нужно запустить наш сервер. В этой статье я буду работать только с сервером разработки Vault. Однако важно отметить, что сервер разработки невероятно небезопасен и хранит все данные в памяти, а это означает, что при его перезапуске все будет потеряно. По словам самих HashiCorp:

Сервер разработки следует использовать для экспериментов с функциями Vault, такими как: различные методы аутентификации, механизмы секретов, устройства аудита и т. д.

Как видите, на экран выводится много данных, с которыми вы можете поиграть. Прежде всего следует отметить, что сервер разработки по умолчанию не запускается как демон (и в целях тестирования, никогда не должен запускаться как демон). Следовательно, если вы хотите взаимодействовать с сервером, вы должны сначала открыть второе окно терминала и экспортировать предоставленную переменную среды VAULT_ADDR, чтобы команда Vault хранилища знала, с каким сервером она должна взаимодействовать.

Также важно отметить значения Unseal Key и Root Token. Хотя мы коснемся того, что делать с Root Token в следующем разделе, понимание запечатывания / распечатывания Vault имеет решающее значение для правильного развертывания Vault в производственной среде.

Расшифровка и аутентификация

В производственной среде сервер Vault запускается в закрытом состоянии. Это означает, что Vault знает, где находятся данные, но не знает, как их расшифровать. На сервере разработки Vault по умолчанию не запечатан (unsealed). Однако, если вы решите запечатать его, вы получите ключ распечатки (Unseal Key), чтобы распечатать (unseal) его. Незапечатанный Vault остается в этом состоянии до тех пор, пока оно не будет повторно запечатано или сам сервер не будет перезапущен.

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

Вход в систему

Хранение секретов

В то время как Vault HashiCorp можно использовать для безопасного хранения практически любых данных, наиболее распространенным вариантом использования Vault является хранилище ключей и значений для секретов приложений. После проверки подлинности хранение секретов становится невероятно простым благодаря команде vault kv put :

Например, давайте посмотрим, что произойдет, если мы введем новое значение для того же секрета:

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

Извлечение секретов

Хранение секретов — это только половина дела. Другая половина — извлекать эти секреты. В нашем примере выше давайте сначала посмотрим, как получить весь список секретов:

Как видите, хотя технически мы помещаем два секрета, отслеживается только один ключ, потому что эти два секрета на самом деле являются всего лишь двумя версиями одного секрета. Чтобы получить его, выполните команду vault kv get с секретным пространством имен и ключом:

Ценность секретов с управлением версиями невероятна, поскольку они позволяют внутренним службам привязаться к различным секретным версиям, что дает возможность постепенно развиваться, выпускать (release) и откатывать изменения приложений, не опасаясь потери важных данных.

Удаление секретов

Это помечает данные как удаленные ( deleted ) и предотвращает их извлечение в обычных запросах GET, но фактически не удаляет данные:

Чтобы данные действительно были удалены без возможности восстановления, необходимо использовать команду destroy:

Вместо того, чтобы просто пометить данные как удаленные и ограничить доступ к ним, команда destroy удалит их полностью, что сделает невозможным последующее извлечение:

Копаем глубже в HashiCorp Vault

Vault — сложный инструмент, и управление такими секретами — это лишь малая часть того, что можно с его помощью сделать. Хотя тонкости Vault выходят далеко за рамки этой статьи, давайте коснемся лишь нескольких других концепций, которые делают Vault таким мощным.

Secrets engines

Хранилище ключей и значений по умолчанию в Vault является примером механизма секретов (в частности, механизма под названием kv ). По своей сути алгоритм секретов — это абстрактный механизм хранения секретных данных. Это означает, что вместо механизма хранения на основе ключа-значения можно использовать более целевые механизмы хранения. Например, механизм секретов базы данных может использоваться для динамического генерирования учетных данных базы данных ( database ) на основе настроенных ролей для MySQL и MariaDB, что позволяет производить автоматическую ротацию учетных данных root или даже временные учетные данные для доступа по запросу.

Методы аутентификации

В дополнение к стандартному методу аутентификации на основе токенов Vault поддерживает ряд дополнительных методов аутентификации для лучшей поддержки ваших вариантов использования. Отличным примером этого является метод проверки подлинности GitHub, который можно использовать для автоматического предоставления доступа к Vault разработчикам, принадлежащим к определенной организации GitHub — и даже к определенной группе внутри организации GitHub — с использованием только токена личного доступа. Для более крупных организаций решения единого входа на уровне предприятия, такие как LDAP или Okta, могут использоваться для аутентификации пользователей в Vault.

Авторизация

Авторизация всегда идет рука об руку с аутентификацией. Хотя предоставить глобальный доступ с помощью GitHub или аутентификации на основе токенов несложно, это почти никогда не бывает полным решением. Благодаря политике Vault может быть реализован метод авторизации в стиле RBAC, предоставляющий разным пользователям и группам CRUD-подобный доступ к различным аспектам самого хранилища. В сочетании с одним из более продвинутых методов аутентификации это может стать невероятно мощным инструментом для детального контроля доступа в большой организации.

За пределами Vault

Каким бы мощным ни было Vault, настроить его правильно довольно сложно. Хотя размер и объем различных методов проверки подлинности и механизмов секретов ясно показывают, сколько вы можете сделать с Vault, может быть сложным осмыслить основы управления секретами в контексте информационной безопасности исходного кода. Благодаря впечатляюще большому количеству как официальных, так и общественных библиотек API, получение секретов безопасным способом невероятно просто, и если вы стремитесь стать опытным пользователем Vault, собственная учебная программа Vault HashiCorp – отличный способ для начала изучения.

Помимо безопасности приложений и инфраструктуры, вам нужен план быстрого реагирования на инциденты. Ознакомьтесь с нашим бесплатным руководством «От реактивного к упреждающему: 6 способов трансформации вашего мониторинга и реагирования на инциденты» для создания прозрачных рабочих процессов управления инцидентами с высокой степенью совместной работы.

Источник

Установка, настройка и работа с Hashicorp Vault

В данной инструкции попробуем охватить как можно больше примеров работы с Hashicorp Vault. Мы выполним установку на системы Linux, настоим сервер, сохраним несколько секретов и попробуем получить доступ к данным секретам из различных систем. В качестве Linux рассмотрим Debian и CentOS 7 и 8.

Подготовка

Прежде чем начать, приведем наш сервер в готовность. Установим необходимые пакеты, настроим время и систему безопасности.

Установка пакетов

Нам понадобятся некоторые утилиты. Команды для их установки зависят от используемой системы.

а) Debian:

apt-get install wget chrony curl apt-transport-https

б) CentOS:

yum install wget chrony curl

Настройка времени

Для корректного получения токенов необходимо, чтобы время на сервере было правильное. Задаем необходимый нам часовой пояс:

timedatectl set-timezone Europe/Moscow

* полный перечень вариантов можно посмотреть командой timedatectl list-timezones.

Если у нас в сети есть свой сервер синхронизации времени, открываем на редактирование файл настройки chrony.

а) Debian:

б) CentOS:

Нам нужно поменять источник, с которым мы будем синхронизировать наше время. Данная опция отличается в зависимости от версии системы или дистрибутива.

а) в Debian или CentOS 8:

* в нашем примере мы комментируем тот адрес pool, который был в конфигурации и подставляем адрес нашего сервера dmosk.local.

а) в CentOS 7:

server dmosk.local
#server 0.centos.pool.ntp.org iburst
#server 1.centos.pool.ntp.org iburst
#server 2.centos.pool.ntp.org iburst
#server 3.centos.pool.ntp.org iburst

* в нашем примере мы комментируем адреса server, которые были в конфигурации и подставляем адрес нашего сервера dmosk.local.

Разрешаем автоматический запуск для сервиса синхронизации времени и перезапускаем его.

а) для Debian:

systemctl enable chrony

systemctl restart chrony

б) для CentOS:

systemctl enable chronyd

systemctl restart chronyd

Настройка брандмауэра

Для корректной работы сервиса нам необходимо открыть порт 8200. В зависимости от используемой утилиты управления netfilter мы должны применять разные инструменты.

а) Iptables (как правило, Debian):

Для сохранения правила можно воспользоваться утилитой iptables-persistent:

apt-get install iptables-persistent

б) Firewalld (как правило, для CentOS):

Установка и запуск

Программный продукт поддерживает различные варианты установки. Мы рассмотрим установку из репозитория.

Подключаем официальный репозиторий и устанавливаем пакет vault.

а) Debian:

apt-get install vault

б) CentOS:

Разрешаем автозапуск службы и если она не запущена, стартуем ее:

Установка выполнена. При попытке зайти по адресу https:// :8200/ мы должны увидеть страницу начальной настройки мастер-ключей.

Настройка рабочего окружения

При попытке выполнить любую операцию в командной строке, мы получим ошибку:

Error checking seal status: Get «https://127.0.0.1:8200/v1/sys/seal-status»: x509: cannot validate certificate for 127.0.0.1 because it doesn’t contain any IP SANs

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

Она укажет текущему окружению подключаться к серверу по http. Однако, это приведет к другой ошибке:

Error checking seal status: Error making API request.

URL: GET http://127.0.0.1:8200/v1/sys/seal-status
Code: 400. Raw Message:

Client sent an HTTP request to an HTTPS server.

Она говорит, что мы подключаемся к серверу по незащищенному каналу, когда сервер требует безопасного соединения.

Для решения проблемы открываем файл:

И снимаем комментарии со следующих строк, а также меняем значение для поля address:

listener «tcp» <
address = «127.0.0.1:8201»
tls_disable = 1
>

* так как для https уже используется порт 8200, мы должны поменять предложенный по умолчанию вариант на свой, чтобы не возникало конфликтов при запуске сервиса.

Перезапускаем службу vault:

systemctl restart vault

Обновляем системную переменную VAULT_ADDR:

* обратите внимание, что мы поменяли порт подключения на 8201.

Пробуем вывести на экран статус:

Мы должны получить что-то на подобие:

Чтобы данная системная переменная создавалась каждый раз при входе пользователя в систему, открываем файл:

Распечатывание

После установки, сервер Vault находится в запечатанном (sealed) состоянии. То есть, он не знает, как ему расшифровывать секреты, которые будут храниться в базе.

При попытке выполнить любую операцию с хранилищем секретов мы получим ошибку:

Чтобы исправить ситуацию, нужно выполнить инициализацию сервера — мы получим ключи для распечатывания (Unseal Keys). После необходимо ввести эти ключи и можно будет авторизоваться в системе.

Инициализация, распечатывание и вход

Для начала, нам необходимо инициализировать наш сервер. Это выполняется командой:

vault operator init

Команда нам вернет 5 ключей. Любые 3 из них являются ключами для распечатывания сервера (Unseal Key). Также нам будет предоставлен токен для root (Initial Root Token), с помощью которого можно будет войти в систему vault.

И так, распечатаем наш сервер, введя по очереди 3 команды.

vault operator unseal

vault operator unseal

vault operator unseal

После выполнения каждой команды система будет запрашивать ключ. Необходимо ввести любые 3 из сгенерированных ранее. При правильном вводе ключа, мы будем видеть общую информацию по ключу. А при вводе третьего ключа мы должны увидеть:

Это значит, что сервер больше не запечатан и с ним можно работать.

Теперь необходимо залогиниться в систему командой:

. и ввести ключ root, который мы получили после инициализации.

Мы можем выполнять команды для работы с Hashicorp Vault.

Автоматическое распечатывание

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

Однако, если у нас есть причины автоматически поднимать сервер после перезагрузки, рассмотрим, как это сделать.

Данный способ противоречит безопасности, однако, реальная эксплуатация систем не всегда вписывается в рамки идеальных концепций.

Выполним настройку в несколько шагов.

Создадим каталог для хранения скриптов:

sleep 10
vault operator unseal w1SgHSWyXm+7kwmYk4bFX2rBLG5jKxIn01DMkj57071D
vault operator unseal 38s4+FkxKTTANFZgCwEPFOgJIMwTvLca1j36yYPc3gdx
vault operator unseal 4xlpKVwPuNlskydM/qmCmW22x7WZdfuiFu92HGRNOa8o

* где w1SgHSWyXm+7kwmYk4bFX2rBLG5jKxIn01DMkj57071D, 38s4+FkxKTTANFZgCwEPFOgJIMwTvLca1j36yYPc3gdx и 4xlpKVwPuNlskydM/qmCmW22x7WZdfuiFu92HGRNOa8o — любых 3 токена (из 5 сгенерированных). Обратите внимание, мы задерживаем выполнение скрипта на 10 секунд — на практике, сервис vault может не успеть запуститься, и мы тогда получим ошибку при выполнении команды vault operator unseal.

Разрешаем запуск скрипта на выполнение:

chmod +x /scripts/unseal.sh

Можно, даже, выполнить скрипт:

В итоге, мы распечатаем наш сервер.

2. Автозапуск скрипта при старте системы:

Большинство современных серверных систем работает на основе systemd. Рассмотрим автозапуск с помощью последней.

[Unit]
Description=Vault Auto Unseal Service
After=network.target
After=vault.service

[Service]
Environment=»VAULT_ADDR=http://127.0.0.1:8201″
ExecStart=/scripts/unseal.sh
Type=oneshot
RemainAfterExit=no

* в данном примере мы выполняем одну команду при запуске сервиса — запуск скрипта /scripts/unseal.sh. Перед этим мы создаем системную переменную VAULT_ADDR, чтобы при выполнении команд в скрипте система понимала, к какому серверу подключаться.

Перечитаем конфигурацию для systemd:

Разрешаем автозапуск созданного сервиса:

systemctl enable vault-unseal

Пробуем перезагрузить сервер — vault должен оказаться распечатанным.

Работа с секретами

Наша система полностью готова, чтобы ей пользоваться.

Для начала дадим разрешение на хранение секретов по пути secret:

Мы должны получить ответ:

Success! Enabled the kv secrets engine at: secret/

Теперь выполним простую операцию по созданию секрета. Введем команду, предложенную на официальном сайте разработчика:

vault kv put secret/hello foo=world

* команда kv взаимодействует с хранилищем Vault. В данном примере мы добавляем пару ключ-значение, соответственно foo-world.

Мы должны получить ответ:

Success! Data written to: secret/hello

Посмотреть содержимое можно командой:

vault kv get secret/hello

Также можно внести за раз множество значений:

vault kv put secret/hello foo=world excited=yes

Посмотреть список созданных секретов можно командой:

vault kv list secret

Теперь удалим секрет командой:

vault kv delete secret/hello

Полный перечень команд можно увидеть так:

После чего можно будет получить помощь по конкретной команде vault, например:

Данной информации достаточно, чтобы познакомиться с продуктом. Пойдем дальше.

Версионность и метаданные

Hashicorp Vault поддерживает версионность данных, то есть, мы можем посмотреть определенную версию данных внутри секрета. Однако, по умолчанию, сервис устанавливается с kv версии 1, которая не поддерживает данной операции. При попытке выполнить любую команду, захватывающую версионность, мы получим ошибку:

Metadata not supported on KV Version 1

Для решения необходимо создание механизма kv с поддержкой версии 2. Это делается командой:

Или для ранее созданного пути включаем ведение версионности командой:

vault kv enable-versioning secret/

Теперь занесем 2 раза данные:

vault kv put secret/hello foo=world

vault kv put secret/hello foo=world2

Посмотреть данные определенной версии можно командой:

В нашем примере мы увидим:

* то есть значение, которое вводилось первой командой.

Посмотреть метаданные секрета можно командой:

vault kv metadata get secret/hello

Для удаления определенной версии секрета вводим:

Динамические секреты

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

Рассмотрим пример настройки динамических секретов для базы данных MariaDB/MySQL.

Первым делом, создадим пользователя в СУБД с правами создавать других пользователей. Подключаемся к базе данных:

Создаем учетную запись, под которой будет подключаться vault к СУБД:

> CREATE USER ‘vaultuser’@’localhost’ IDENTIFIED BY ‘vaultpass’;

Дадим права созданной учетной записи создавать других пользователей и назначать им права:

> GRANT CREATE USER ON *.* TO ‘vaultuser’@’localhost’ WITH GRANT OPTION;

Выходим из оболочки SQL:

Теперь разрешаем механизм секретов базы данных (database secrets engine):

vault secrets enable database

Success! Enabled the database secrets engine at: database/

* также мы можем получить ошибку path is already in use at database/, если данный механизм уже разрешен в нашей системе.

Создадим настройку для подключения к нашей базе:

vault write database/config/test \
plugin_name=mysql-database-plugin \
connection_url=»<>:<>@tcp(127.0.0.1:3306)/» \
allowed_roles=»test-role» \
username=»vaultuser» \
password=»vaultpass»

Создадим роль, по сути, зададим команду для создания временной учетной записи:

vault write database/roles/test-role \
db_name=test \
creation_statements=»CREATE USER ‘<>’@’%’ IDENTIFIED BY ‘<>’; GRANT SELECT ON *.* TO ‘<>’@’%’;» \
default_ttl=»1h» \
max_ttl=»24h»

И так, теперь давайте создадим пользователя и пароль:

vault read database/creds/test-role

* после ввода команды vault сгенерирует и создаст в базе нового пользователя и пароль.

Мы должны увидеть что-то на подобие:

* Если мы увидим ошибку, на подобие Error 1470: String ‘v-root-test-role-KHWyA2IwdoaUth7c’ is too long for user name (should be no longer than 16) мы столкнулись с ограничением на стороне СУБД (нельзя создавать имя пользователя с длиной более 16 символов). Чтобы решить проблему мы должны пересоздать подключение database/config/test с новым плагином mysql-legacy-database-plugin.

Также для создания пользователя мы можем использовать API запрос:

* где X-Vault-Token — токен с доступом. Для теста можно использовать тот, что был получен для root после инициализации системы.

Теперь давайте проверим, что созданные учетные записи имеют нужный нам доступ. Для начала, под пользователем root можно проверить, что записи созданы:

> SELECT user, host FROM mysql.user;

Мы должны увидеть в списках нужную запись (в нашем примере, v-test—gVPavnGVr).

Теперь зайдем под учетной записью, которая была создана с помощью vault:

* в моем случае из-за доступа %, подключение с localhost было запрещено. Поэтому я проверяю доступ с другого хоста в локальной сети, добавив опцию -h192.168.0.15 (где 192.168.0.15 — сервер с СУБД, доступ к которой предоставлялся через vault).

Мы должны подключиться к базе.

Отменить доступ можно командой:

vault lease revoke database/creds/test-role/JpEmEh2MJV115Lr4S4Lx5UHW

* где database/creds/test-role/JpEmEh2MJV115Lr4S4Lx5UHW — значение lease_id, которое нам вернула система при создании временной учетной записи.

Посмотреть список всех идентификатором можно командой:

vault list sys/leases/lookup/database/creds/test-role

* где test-role — имя созданной нами роли.

Продлить lease_duration или default_ttl (пароль) можно с помощью команды:

vault lease renew database/creds/test-role/JpEmEh2MJV115Lr4S4Lx5UHW

Аутентификация и политики

Hashicorp Vault позволяет управлять доступами с помощью политик и токенов авторизации. Рассмотрим процесс настройки.

Работа с токенами

Для начала научимся управлять токенами. Простая команда для создания нового:

vault token create

Система сгенерирует новый ключ и сделает вывод на экран.

Также мы можем создать временный токен:

Посмотреть информацию о токене можно через его аксессор. Сначала получим список аксессоров:

vault list auth/token/accessors

После смотрим токен по аксессору:

Войти в систему с помощью токена можно командой:

После вводим наш токен. Или одной командой:

vault login s.Db9j6Q4TvyFDr3j2aQmXttrX

Посмотреть информацию о токене, под которым мы зарегистрировались в системе, можно командой:

vault token lookup

А данной командой мы создаем пользователя и привязываем его к политике my-policy:

Если политики нет в системе, то мы получим предупреждение:

WARNING! The following warnings were returned from Vault:

* Policy «my-policy» does not exist

Нас это не должно заботить — на следующем шаге мы ее создадим.

При необходимости привязать токен к нескольким политикам, перечисляем из в опциях policy:

Работа с политиками

Выше мы создали токен и привязали его к политике my-policy. Создадим ее:

URL: PUT http://127.0.0.1:8201/v1/secret/data/hello/new
Code: 403. Errors:

* 1 error occurred:
* permission denied

Теперь логинимся под токеном с полными правами и добавим запись:

vault kv put secret/hello/new foo=world

И снова заходим под токеном с ограниченными правами. Пробуем обновить запись:

vault kv put secret/hello/new foo=world2

Команда должна выполниться успешно, так как мы разрешили политикой обновлять записи.

Аутентификация на основе пользователей

Также в Hashicorp Vault мы можем создать пользователя с паролем и привязать к нему политику. Администратор сможем входить в систему под учетной записью, а не с помощью токена.

Разрешаем метод auth по пути userpass:

vault auth enable userpass

vault write auth/userpass/users/dmosk password=»test-pass» policies=»my-profile»

* данной командой мы создали пользователя dmosk с паролем test-pass и привязали его к политике my-profile.

Войти в систему можно командой:

Вводим пароль и попадаем в систему под пользователем dmosk. Можно выполнить тесты, которые мы делали выше.

Одноразовые SSH пароли

Рассмотрим варианты хранения секретов для авторизации по SSH с использованием одноразовых паролей или One-Time SSH Password (OTP).

Настройка на сервере Vault

Разрешаем механизм ssh:

vault secrets enable ssh

Создаем роль для создания одноразового пароля:

vault write ssh/roles/otp_key_role \
key_type=otp \
default_user=test \
cidr_list=10.0.2.0/24

На сервере, пока, все. Переходим к настройке клиента.

Настройка на клиенте

На клиенте необходимо выполнить настройку, которая позволит выполнять две задачи:

Данной задачей занимается vault-ssh-helper. Рассмотрим процесс его установки и настройки.

Нам понадобится пакет для распаковки zip-архивов. В зависимости от системы ставим его одной из команд ниже.

а) для Debian / Ubuntu:

apt-get install unzip

б) для CentOS / Red Hat / Fedora:

Установка vault-ssh-helper выполняется простым копированием бинарника. Переходим на официальный сайт для загрузки и выбираем последнюю версию пакета. На следующей страницы копируем ссылку на нужный вариант архива, в зависимости от архитектуры нашего сервера:

С помощью скопированной ссылки загружаем архив:

Создадим каталог для конфигурационных файлов vault-ssh-helper:

Создадим конфигурационный файл:

vault_addr = «https://192.168.0.20:8200»
ssh_mount_point = «ssh»
tls_skip_verify = true
allowed_roles = «*»

Открываем конфигурационный файл pamd для sshd:

И в самый верх добавляем:

* в данной конфигурации мы, по-прежнему, сможем авторизоваться под учетными записями, созданными на самом сервере. Если необходимо это отключить, разрешив вход только с OTP, комментируем @include common-auth и меняем sufficient на required.

Наконец, редактируем конфигурационный файл sshd. Открываем его:

Выставляем следующие значения для опций:

ChallengeResponseAuthentication yes
.
UsePAM yes

* где ChallengeResponseAuthentication разрешает авторизацию с применением интерактивного ввода пароля; UsePAM разрешает использование модуля pam.

Перезапустим сервис ssh:

systemctl restart sshd

Выполняем проверку нашей настройки командой:

Мы должны получить ответ:

2021/05/18 14:07:14 [INFO] using SSH mount point: ssh
2021/05/18 14:07:14 [INFO] using namespace:
2021/05/18 14:07:14 [INFO] vault-ssh-helper verification successful!

Значит настройка на клиенте выполнена коррекнто.

Создаем учетную запись на клиенте, под которой будем входить в систему с одноразовым паролем:

* в нашей политике будет создаваться пароль для учетной записи test.

Создаем одноразовый пароль

vault write ssh/creds/otp_key_role ip=192.168.0.25

* в данном примере мы создаем одноразовый пароль для компьютера с IP-адресом 192.168.0.25.

Мы должны получить, примерено, такой вывод:

* мы получили одноразовый пароль 83a57021-74b0-3ce3-8179-6fb92288c0ce.

Пробуем войти в систему:

Вводим тот пароль, который нам выдала система (key). Войти мы сможем только один раз, после нужно будет уже генерировать новый пароль.

Настройка SSL

В инструкции выше мы настроили наше окружение для локального подключения по http. Данный метод временный, так как не позволит управлять системой с другого компьютера или придется жертвовать безопасностью. Рассмотрим процесс настройки запросов по защищенному протоколу https.

Первое, что нам нужно, это получить сертификат. Правильнее всего купить сертификат или запросить через Let’s Encrypt. После прописать в конфигурационном файле vault путь до данного сертификата. Но мы рассмотрим процесс получения самоподписанного сертификата, но при этом, который примет система. Для этого необходимо выполнить несколько условий:

И так, создаем каталог для хранения сертификатов:

Проверяем версию openssl:

Она должна быть 1.1.1 и выше. В противном случае, необходимо выполнить обновление OpenSSL. Как правило, данное действие требуется только на CentOS 7.

* в данном примере мы сгенерируем необходимые ключи по пути /etc/ssl/vault; обязательно, нужно поменять значения vault.dmosk.local на имя сервера, который используется у вас.

Если команда вернет ошибку, проверяем, что у нас обновленная версия openssl, которая поддерживает ключ addext.

Теперь откроем конфигурационный файл hashicorp vault:

Приведем секцию HTTPS listener к виду:

# HTTPS listener
listener «tcp» <
address = «0.0.0.0:8200»
tls_cert_file = «/etc/ssl/vault/cert.pem»
tls_key_file = «/etc/ssl/vault/cert.key»
>

* необходимо поменять пути до файлов tls_cert_file и tls_key_file.

После перезагрузки сервиса, он станет запечатанным и нам нужно будет снова ввести 3 части ключа (команды vault operator unseal).

systemctl restart vault

Меняем в окружении переменную VAULT_ADDR:

* мы указываем протокол https, обращения должны выполняться по доменному имени, для которого мы получили сертификат; также указываем порт 8200.

Мы должны получить состояние системы. Значит запросы по https работают.

И последнее, снова открываем файл:

И также меняем значение для переменной VAULT_ADDR:

Запуск в виде контейнера Docker

В инструкции мы рассмотрели установку Hashicorp Vault как пакета. Также мы можем установить данный сервис в виде контейнера Docker из официального образа. Рассмотрим вкратце данный вопрос.

Для начала, необходимо установить в систему Docker. После загружаем образ

Для запуска vault в режиме сервера вводим:

После заходим внутрь контейнера:

Задаем системную переменную для подключения к vault по http:

Источник