Update USAGE_RU.md

Заменено название Vault при упоминании работы Stronghold

Signed-off-by: farr-slmn <farr.slmn@gmail.com>

docs/USAGE_RU.md

@@ -55,7 +55,7 @@ spec:
 ## Подготовка тестового окружения
 
 {{< alert level="info">}}
-Для выполнения дальнейших команд необходим адрес и токен с правами root от Vault.
+Для выполнения дальнейших команд необходим адрес и токен с правами root от Stronghold.
 Такой токен можно получить во время инициализации нового secrets store.
 
 Далее в командах будет подразумеваться что данные настойки указаны в переменных окружения.
@@ -152,7 +152,7 @@ export VAULT_ADDR=https://secretstoreexample.com
     ${VAULT_ADDR}/v1/auth/remote-kube-1/config
   ```
 
-* Создаём в Vault политику с названием `backend`, разрешающую чтение секрета `myapp`:
+* Создаём в Stronghold политику с названием `backend`, разрешающую чтение секрета `myapp`:
 
   ```bash
   stronghold policy write backend - <<EOF
@@ -234,7 +234,7 @@ export VAULT_ADDR=https://secretstoreexample.com
 
 Stronghold может использовать различные авторизационные данные для осуществления запросов в API Kubernetes:
 1. Использовать токен приложения, которое пытается авторизоваться в Stronghold. В этом случае для каждого сервиса авторизующейся в Stronghold требуется в используемом ServiceAccount иметь clusterRole `system:auth-delegator` (либо права на API представленные выше). 
-2. Использовать статичный токен отдельно созданного специально для Vault `ServiceAccount` у которого имеются необходимые права. Настройка Vault для такого случая подробно описана в [документации Vault](https://developer.hashicorp.com/vault/docs/auth/kubernetes#continue-using-long-lived-tokens).
+2. Использовать статичный токен отдельно созданного специально для Stronghold `ServiceAccount` у которого имеются необходимые права. Настройка Stronghold для такого случая подробно описана в [документации Vault](https://developer.hashicorp.com/vault/docs/auth/kubernetes#continue-using-long-lived-tokens).
 
 ## Инжектирование переменных окружения
 
@@ -430,7 +430,7 @@ spec:
       volumeAttributes:
         secretsStoreImport: "myapp-ssi"
 ```
-После применения этих ресурсов будет запущен под с названием `backend`, внутри которого будет каталог `/mnt/secrets` с примонтированным внутрь томом `secrets`. Внутри каталога будет лежать файл `db-password` с паролем от базы данных из Vault.
+После применения этих ресурсов будет запущен под с названием `backend`, внутри которого будет каталог `/mnt/secrets` с примонтированным внутрь томом `secrets`. Внутри каталога будет лежать файл `db-password` с паролем от базы данных из Stronghold.
 
 Проверьте логи пода после его запуска (должно выводиться содержимое файла `/mnt/secrets/db-password`):
 ```bash
@@ -445,7 +445,7 @@ kubectl -n my-namespace delete pod myapp3 --force
 
 ### Функция авторотации
 
-Функция авторотации секретов в модуле secret-store-integration включена по умолчанию. Каждые две минуты модуль опрашивает Vault и синхронизирует секреты в примонтированном файле в случае его изменения.
+Функция авторотации секретов в модуле secret-store-integration включена по умолчанию. Каждые две минуты модуль опрашивает Stronghold и синхронизирует секреты в примонтированном файле в случае его изменения.
 
 Есть два варианта следить за изменениями файла с секретом в поде. Первый - следить за временем изменения примонтированного файла, реагируя на его изменение. Второй - использовать inotify API, который предоставляет механизм для подписки на события файловой системы. Inotify является частью ядра Linux. После обнаружения изменений есть большое количество вариантов реагирования на событие изменения в зависимости от используемой архитектуры приложения и используемого языка программирования. Самый простой — заставить K8s перезапустить под, перестав отвечать на liveness-пробу.