Updates

docs/FAQ.md

@@ -3,7 +3,7 @@ title: "The secrets-store-integration module: FAQ"
 description: Hashicorp vault example configuration. Example of secret autorotation implementation.
 ---
 
-## How to set up the Hashicorp vault as a secret store for use with the secrets-store-integration module:
+## How to set up the Hashicorp Vault as a secret store for use with the secrets-store-integration module:
 
 First of all, we need a root or similiar token and the vault address.
 Root token can be obtained during new secrets store initialization.
@@ -15,8 +15,8 @@ export VAULT_ADDR=https://secretstoreexample.com
 ```
 
 In this guide we provide two ways to obtain needed result: 
-- usage of the console version of the Hashicorp Vault (Installation guide: https://developer.hashicorp.com/vault/docs/install)
-- usage of the cURL equivalent command to make a direct requests to the secrets store API
+- usage of the console version of the Hashicorp Vault (installation guide: https://developer.hashicorp.com/vault/docs/install);
+- usage of the curl equivalent command to make a direct requests to the secrets store API.
 
 Enable and create Key-Value storage:
 

docs/FAQ_RU.md

@@ -3,9 +3,9 @@ title: "Модуль secrets-store-integration: FAQ"
 description: Как настроить HashiCorp Vault в качестве secret store. Пример реализации авторотации секретов.
 ---
 
-## Как настроить HashiCorp vault в качестве secret store для использования с модулем secrets-store-integration?
+## Как настроить HashiCorp Vault в качестве secret store для использования с модулем secrets-store-integration?
 
-Прежде всего нам необходим адрес и токен с правами root от Vault:
+Прежде всего нам необходим адрес и токен с правами root от Vault.
 Такой токен с правами root можно получить во время инициализации нового secrets store.
 
 ```bash
@@ -14,8 +14,8 @@ export VAULT_ADDR=https://secretstoreexample.com
 ```
 
 В этом руководстве мы приводим два вида примерных команд: 
-- команда с использованием консольной версии HashiCorp Vault (Руководство по установке: https://developer.hashicorp.com/vault/docs/install)
-- команда с использованием cURL для выполнения прямых запросов в API secrets store
+- команда с использованием консольной версии HashiCorp Vault (руководство по установке: https://developer.hashicorp.com/vault/docs/install);
+- команда с использованием curl для выполнения прямых запросов в API secrets store.
 
 Включим и создадим Key-Value хранилище:
 
@@ -129,7 +129,7 @@ curl \
   ${VAULT_ADDR}/v1/auth/secondary-kube/config
 ```
 
-Создаём в Vault политику с названием "backend", разрешающую чтение секретов:
+Создаём в Vault политику с названием «backend», разрешающую чтение секретов:
 
 ```bash
 vault policy write backend - <<EOF
@@ -149,7 +149,7 @@ curl \
   ${VAULT_ADDR}/v1/sys/policies/acl/backend
 ```
 
-Создаём роль, состоящую из названия неймспейса и приложения. Связываем её с ServiceAccount "backend-sa" из нашего неймспейса "my-namespace1" и политикой "backend":
+Создаём роль, состоящую из названия пространства имён и приложения. Связываем её с ServiceAccount «backend-sa» из пространства имён «my-namespace1» и политикой «backend»:
 
 ```bash
 vault write auth/main-kube/role/my-namespace1_backend \
@@ -169,7 +169,7 @@ curl \
   ${VAULT_ADDR}/v1/auth/main-kube/role/my-namespace1_backend
 ```
 
-Повторяем тоже самое для второго кластера, указав другой путь аутентификации:
+Повторяем то же самое для второго кластера, указав другой путь аутентификации:
 
 ```bash
 vault write auth/secondary-kube/role/my-namespace1_backend \
@@ -191,7 +191,7 @@ curl \
 
 **Рекомендованное значение TTL для токена Kubernetes составляет 10m.**
 
-Эти настройки позволяют любому поду из неймспейса "my-namespace1" из обоих k8s кластеров, который использует ServiceAccount "backend-sa", аутентифицироваться и авторизоваться в Vault для чтения секретов согласно политике "backend".
+Эти настройки позволяют любому поду из пространства имён «my-namespace1» из обоих K8s-кластеров, который использует ServiceAccount «backend-sa», аутентифицироваться и авторизоваться в Vault для чтения секретов согласно политике «backend».
 
 ## Как использовать авторотацию секретов, примонтированных как файл в контейнер без его перезапуска?
 
@@ -258,10 +258,10 @@ spec:
           volumeAttributes:
             secretsStoreImport: "python-backend"
 ```
-`
-После применения этих ресурсов будет запущен под с названием `backend`, внутри которого будет папка `/mnt/secrets` с примонтированным внутрь томом secrets. Внутри папки будет лежать файл `db-password` с паролем от базы данных из Vault.
 
-Есть два варианта следить за изменениями файла с секретом в поде. Первый - следить за временем изменения примонтированного файла, реагируя на его изменение. Второй - использовать inotify API, который предоставляет механизм для подписки на события файловой системы. Inotify является частью ядра Linux. После обнаружения изменений есть большое количество вариантов как реагировать на событие изменения в зависимости от используемой архитектуры приложения и используемого языка программирования. Самый простой - заставить K8s перезапустить pod, перестав отвечать на liveness пробу.
+После применения этих ресурсов будет запущен под с названием `backend`, внутри которого будет каталог `/mnt/secrets` с примонтированным внутрь томом `secrets`. Внутри каталога будет лежать файл `db-password` с паролем от базы данных из Vault.
+
+Есть два варианта следить за изменениями файла с секретом в поде. Первый - следить за временем изменения примонтированного файла, реагируя на его изменение. Второй - использовать inotify API, который предоставляет механизм для подписки на события файловой системы. Inotify является частью ядра Linux. После обнаружения изменений есть большое количество вариантов реагирования на событие изменения в зависимости от используемой архитектуры приложения и используемого языка программирования. Самый простой — заставить K8s перезапустить под, перестав отвечать на liveness-пробу.
 
 Пример использования inotify в приложении на Python с использованием пакета inotify:
 

docs/README.md

@@ -7,7 +7,7 @@ The secrets-store-integration module implements the delivery of secrets to appli
 cluster by mounting multiple secrets, keys, and certificates stored in external secrets stores.
 
 Secrets are mounted into pods as a volume using CSI driver implementation.
-Secrets stores must be compatible with Hashicorp Vault API.
+Secrets stores must be compatible with HashiCorp Vault API.
 
 ## Delivering secrets to the applications
 
@@ -75,7 +75,7 @@ There are several ways to deliver secrets to an application from vault-compatibl
 
 ### Option #1: Get the secrets from the app itself
 
-> *Status:* The most secure option. Recommended for use if there is a possibility of application modification.
+> *Status:* the most secure option. Recommended for use if there is a possibility of application modification.
 
 The application accesses Stronghold API and requests the necessary secret via HTTPS protocol using authorization token (token from SA).
 
@@ -94,15 +94,15 @@ The application accesses Stronghold API and requests the necessary secret via HT
 
 #### CSI interface
 
-> *Status:* Secure option. Recommended for use if there is no way to modify applications.
+> *Status:* secure option. Recommended for use if there is no way to modify applications.
 
 When creating pods requesting CSI volumes, the CSI secret vault driver sends a request to Vault CSI. Vault CSI then uses the specified SecretProviderClass and ServiceAccount feed to retrieve secrets from the vault and mount them in the pod volume.
 
 #### Environment Variable Injection:
 
 In a situation where there is no way to modify the application code, then you can implement secure secret injection as an environment variable for the application. To do this, read all the files CSI has mounted in the container and define environment variables with names corresponding to the file names and values corresponding to the contents of the files. After that, run the original application.
 
-Example in bash:
+Example in Bash:
 
 ```bash
 bash -c "for file in $(ls /mnt/secrets); do export  $file=$(cat /mnt/secrets/$file); done ; exec my_original_file_to_startup"
@@ -119,13 +119,13 @@ bash -c "for file in $(ls /mnt/secrets); do export  $file=$(cat /mnt/secrets/$fi
 
 #### Environment variables delivery into the container through entrypoint injection
 
-> *Статус:* Secure option. In the process of implementation
+> *Статус:* secure option. In the process of implementation
 
 Environment variables are being delivered into the container during the application start and are located only in memory. During the first stage of implementation delivery will be made with the entrypoint injection. Afterwards, delivery mechanism will be integrated into containerd.
 
 ### Option #4: Delivering secrets through Kubernetes mechanisms
 
-> *Status:* Not a safe option, not recommended for use. No support is available, but it is planned for the future.
+> *Status:* not a safe option, not recommended for use. No support is available, but it is planned for the future.
 
 This integration method implements a Kubernetes secrets operator with a set of CRDs responsible for synchronizing secrets from Vault to Kubernetes secrets.
 
@@ -139,7 +139,7 @@ This integration method implements a Kubernetes secrets operator with a set of C
 
 ### For reference: vault-agent injector
 
-> *Status:* Has no pros compared to the CSI mechanism. No support and implementation is available or planned.
+> *Status:* has no pros compared to the CSI mechanism. No support and implementation is available or planned.
 
 When a pod is created, a mutation occurs that adds a vault-agent container. The vault-agent accesses the secret store, retrieves the secret, and places it into a shared volume on a disk that can be accessed by the application.