Подключите поставщика удостоверений Azure к драйверу CSI хранилища секретов Azure Key Vault в Служба Azure Kubernetes (AKS)

Драйвер хранилища контейнеров хранилища секретов (CSI) в Служба Azure Kubernetes (AKS) предоставляет различные методы доступа на основе удостоверений к Azure Key Vault. В этой статье описаны эти методы и рекомендации по использованию моделей безопасности на основе ролей (RBAC) или OpenID Connect (OIDC) для доступа к хранилищу ключей и кластеру AKS.

Вы можете использовать один из следующих методов доступа:

• Соединитель службы с управляемым удостоверением
• Идентификация рабочей нагрузки
• Управляемое удостоверение, назначаемое пользователем

Узнайте, как подключиться к Azure Key Vault с помощью драйвера CSI хранилища секретов в кластере Служба Azure Kubernetes (AKS) с помощью соединителя службы. В этой статье вы выполните следующие задачи:

• Создайте кластер AKS и Azure Key Vault.
• Создайте подключение между кластером AKS и Azure Key Vault с помощью соединителя службы.
• SecretProviderClass Создайте CRD и идентификаторPod, который использует поставщик CSI для проверки подключения.
• Очистите ресурсы.

Внимание

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

• Политики поддержки AKS
• Часто задаваемые вопросы о поддержке Azure

Необходимые компоненты

• Учетная запись Azure с активной подпиской. Создайте учетную запись бесплатно .
• Интерфейс командной строки Azure. Войдите с помощью az login команды.
• Docker и kubectl. Чтобы установить kubectl локально, используйте az aks install-cli команду.
• Базовое представление о контейнерах и AKS. Начало работы с подготовкой приложения для AKS.
• Прежде чем начать, выполните действия, описанные в разделе "Использование поставщика Azure Key Vault для драйвера CSI хранилища секретов" в кластере Служба Azure Kubernetes (AKS), чтобы включить драйвер CSI хранилища секретов Хранилища ключей Azure в кластере AKS.

Начальная настройка

1. Если вы впервые используете соединитель служб, начните с запуска команды az provider register , чтобы зарегистрировать соединитель службы и поставщики ресурсов конфигурации Kubernetes.

   az provider register -n Microsoft.ServiceLinker
   

   az provider register -n Microsoft.KubernetesConfiguration
   

   Совет

   Вы можете проверить, зарегистрированы ли эти поставщики az provider show -n "Microsoft.ServiceLinker" --query registrationState ресурсов, выполнив команды и az provider show -n "Microsoft.KubernetesConfiguration" --query registrationState.

2. При необходимости используйте команду Azure CLI, чтобы получить список поддерживаемых целевых служб для кластера AKS.

   az aks connection list-support-types --output table
   

Создание ресурсов Azure

1. Создайте группу ресурсов с помощью az group create команды.

   az group create \
       --name <resource-group-name> \
       --location <location>
   

2. Создайте кластер AKS с помощью az aks create команды. В следующем примере создается кластер AKS с поддержкой управляемого удостоверения.

   az aks create \
       --resource-group <resource-group-name> \
       --name <cluster-name> \
       --enable-managed-identity \
       --node-count 1
   

3. Подключитесь к кластеру az aks get-credentials с помощью команды.

   az aks get-credentials \
       --resource-group <resource-group-name> \
       --name <cluster-name>
   

4. Создайте хранилище ключей Azure с помощью az keyvault create команды.

   az keyvault create \
       --resource-group <resource-group-name> \  
       --name <key-vault-name> \
       --location <location>
   

5. Создайте секрет в хранилище ключей с помощью az keyvault secret set команды.

   az keyvault secret set \
       --vault-name <key-vault-name> \
       --name <secret-name> \
       --value <secret-value>
   

Создание подключения службы в AKS с помощью соединителя службы (предварительная версия)

Подключение службы к Azure Key Vault можно создать с помощью портал Azure или Azure CLI.

Портал Azure

1. В портал Azure перейдите к ресурсу кластера AKS.

2. В меню службы в разделе "Параметры" выберите "Соединитель служб" (предварительная версия)>Создать.

3. На странице "Создание подключения" настройте следующие параметры на вкладке "Основные сведения".

   • Пространство имен Kubernetes: выберите значение по умолчанию.
   • Тип службы: выберите Key Vault и установите флажок, чтобы включить поставщик CSI Azure Key Vault.
   • Имя подключения: введите имя подключения.
   • Подписка. Выберите подписку, содержащую хранилище ключей.
   • Хранилище ключей: выберите созданное хранилище ключей.
   • Тип клиента: select None.

4. Выберите "Просмотр и создание", а затем нажмите кнопку "Создать ", чтобы создать подключение.

Azure CLI

• Создайте подключение к хранилищу ключей az aks connection create keyvault с помощью команды.

  az aks connection create keyvault \
      --connection <connection-name> \
      --resource-group <resource-group-of-cluster> \
      --name <cluster-name> \
      --target-resource-group <resource-group-of-key-vault> \
      --vault <key-vault-name> \
      --enable-csi \
      --client-type none
  
  

Проверка подключения

Клонирование примера репозитория и развертывание файлов манифеста

1. Клонируйте пример репозитория с помощью git clone команды.

   git clone https://github.com/Azure-Samples/serviceconnector-aks-samples.git
   

2. Измените каталоги на пример поставщика CSI в Azure Key Vault.

   cd serviceconnector-aks-samples/azure-keyvault-csi-provider
   

3. secret_provider_class.yaml В файле замените следующие заполнители данными Azure Key Vault:

   • Замените <AZURE_KEYVAULT_NAME> именем созданного и подключенного хранилища ключей.
   • Замените <AZURE_KEYVAULT_TENANTID> идентификатором клиента хранилища ключей.
   • Замените <AZURE_KEYVAULT_CLIENTID> идентификатором клиента удостоверения надстройки azureKeyvaultSecretsProvider .
   • Замените <KEYVAULT_SECRET_NAME> созданный секрет хранилища ключей. Например, ExampleSecret.

4. SecretProviderClass Разверните CRD с помощью kubectl apply команды.

   kubectl apply -f secret_provider_class.yaml
   

5. Разверните файл манифеста Pod kubectl apply с помощью команды.

   Команда создает pod с именем sc-demo-keyvault-csi в пространстве имен по умолчанию кластера AKS.

   kubectl apply -f pod.yaml
   

Проверка подключения

1. Убедитесь, что модуль pod был успешно создан с помощью kubectl get команды.

   kubectl get pod/sc-demo-keyvault-csi
   

   После запуска модуля будет доступно подключенное содержимое по пути к тому, указанному в YAML развертывания.

2. Отображение секретов в хранилище секретов с помощью kubectl exec команды.

   kubectl exec sc-demo-keyvault-csi -- ls /mnt/secrets-store/
   

3. Отображение секрета kubectl exec с помощью команды.

   В этом примере команды показано имя тестового ExampleSecretсекрета.

   kubectl exec sc-demo-keyvault-csi -- cat /mnt/secrets-store/ExampleSecret
   

Предварительные требования для драйвера CSI

• Прежде чем начать, выполните действия, описанные в разделе "Использование поставщика Azure Key Vault для драйвера CSI хранилища секретов" в кластере Служба Azure Kubernetes (AKS), чтобы включить драйвер CSI хранилища секретов Хранилища ключей Azure в кластере AKS.
• Идентификация рабочей нагрузки Microsoft Entra поддерживает кластеры Windows и Linux.

Доступ с помощью Идентификация рабочей нагрузки Microsoft Entra

Идентификация рабочей нагрузки Microsoft Entra — это удостоверение, которое приложение, работающее в модуле pod, использует для проверки подлинности в других службах Azure, таких как рабочие нагрузки в программном обеспечении. Драйвер CSI хранилища секретов интегрируется с собственными возможностями Kubernetes для федерации с внешними поставщиками удостоверений.

В этой модели безопасности кластер AKS выступает в качестве издателя маркеров. Затем идентификатор Microsoft Entra использует OIDC для обнаружения открытых ключей подписывания и проверки подлинности маркера учетной записи службы перед обменом на токен Microsoft Entra. Чтобы рабочая нагрузка обменилась маркером учетной записи службы, проецируемым на его том для маркера Microsoft Entra, вам потребуется клиентская библиотека удостоверений Azure в пакете SDK Azure или библиотеке проверки подлинности Майкрософт (MSAL)

Примечание.

• Этот метод проверки подлинности заменяет управляемое модулем Microsoft Entra pod (предварительная версия). Управляемое модулем открытый код Microsoft Entra pod (предварительная версия) в Служба Azure Kubernetes устарело по состоянию на 10.24.2022.
• Идентификация рабочей нагрузки Microsoft Entra поддерживает кластеры Windows и Linux.

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

1. Задайте подписку az account set с помощью команды.

   export SUBSCRIPTION_ID=<subscription id>
   export RESOURCE_GROUP=<resource group name>
   export UAMI=<name for user assigned identity>
   export KEYVAULT_NAME=<existing keyvault name>
   export CLUSTER_NAME=<aks cluster name>
   
   az account set --subscription $SUBSCRIPTION_ID
   

2. Создайте управляемое удостоверение с помощью az identity create команды.

   Примечание.

   На этом шаге предполагается, что у вас есть существующий кластер AKS с включенным удостоверением рабочей нагрузки. Если она не включена, см . раздел "Включить удостоверение рабочей нагрузки" в существующем кластере AKS, чтобы включить его.

   az identity create --name $UAMI --resource-group $RESOURCE_GROUP
   
   export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group $RESOURCE_GROUP --name $UAMI --query 'clientId' -o tsv)"
   export IDENTITY_TENANT=$(az aks show --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --query identity.tenantId -o tsv)
   

3. Создайте назначение ролей, которое предоставляет удостоверению рабочей нагрузки разрешение на доступ к секретам хранилища ключей, ключам доступа и сертификатам с помощью az role assignment create команды.

   Внимание

   • Если хранилище ключей задано, --enable-rbac-authorization и вы используете key или certificate вводите ее, назначьте Key Vault Certificate User роль для предоставления разрешений.
   • Если хранилище ключей задано и --enable-rbac-authorization используется secret тип, назначьте Key Vault Secrets User роль.
   • Если хранилище ключей не задано--enable-rbac-authorization, можно использовать az keyvault set-policy команду с --key-permissions get--certificate-permissions getпараметром или --secret-permissions get параметром для создания политики хранилища ключей для предоставления доступа к ключам, сертификатам или секретам. Например:

   az keyvault set-policy --name $KEYVAULT_NAME --key-permissions get --object-id $IDENTITY_OBJECT_ID
   

   export KEYVAULT_SCOPE=$(az keyvault show --name $KEYVAULT_NAME --query id -o tsv)
   
   # Example command for key vault with RBAC enabled using `key` type
   az role assignment create --role "Key Vault Certificate User" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE
   

4. Получите URL-адрес издателя кластера AKS кластера OIDC с помощью az aks show команды.

   Примечание.

   На этом шаге предполагается, что у вас есть существующий кластер AKS с включенным URL-адресом издателя OIDC. Если она не включена, см. статью "Обновить кластер AKS" с помощью издателя OIDC, чтобы включить его.

   export AKS_OIDC_ISSUER="$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query "oidcIssuerProfile.issuerUrl" -o tsv)"
   echo $AKS_OIDC_ISSUER
   

5. Установите учетные данные федеративного удостоверения между приложением Microsoft Entra, издателем учетной записи службы и субъектом. Получите идентификатор объекта приложения Microsoft Entra с помощью следующих команд. Обязательно обновите значения для serviceAccountName имени учетной записи службы Kubernetes и serviceAccountNamespace его пространства имен.

   export SERVICE_ACCOUNT_NAME="workload-identity-sa"  # sample name; can be changed
   export SERVICE_ACCOUNT_NAMESPACE="default" # can be changed to namespace of your workload
   
   cat <<EOF | kubectl apply -f -
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     annotations:
       azure.workload.identity/client-id: ${USER_ASSIGNED_CLIENT_ID}
     name: ${SERVICE_ACCOUNT_NAME}
     namespace: ${SERVICE_ACCOUNT_NAMESPACE}
   EOF
   

6. Создайте учетные данные федеративного удостоверения между управляемым удостоверением, издателем учетной записи службы и субъектом az identity federated-credential create с помощью команды.

   export FEDERATED_IDENTITY_NAME="aksfederatedidentity" # can be changed as needed
   
   az identity federated-credential create --name $FEDERATED_IDENTITY_NAME --identity-name $UAMI --resource-group $RESOURCE_GROUP --issuer ${AKS_OIDC_ISSUER} --subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}
   

7. SecretProviderClass Разверните команду с помощью следующего kubectl apply скрипта YAML.

   cat <<EOF | kubectl apply -f -
   # This is a SecretProviderClass example using workload identity to access your key vault
   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: azure-kvname-wi # needs to be unique per namespace
   spec:
     provider: azure
     parameters:
       usePodIdentity: "false"
       clientID: "${USER_ASSIGNED_CLIENT_ID}" # Setting this to use workload identity
       keyvaultName: ${KEYVAULT_NAME}       # Set to the name of your key vault
       cloudName: ""                         # [OPTIONAL for Azure] if not provided, the Azure environment defaults to AzurePublicCloud
       objects:  |
         array:
           - |
             objectName: secret1             # Set to the name of your secret
             objectType: secret              # object types: secret, key, or cert
             objectVersion: ""               # [OPTIONAL] object versions, default to latest if empty
           - |
             objectName: key1                # Set to the name of your key
             objectType: key
             objectVersion: ""
       tenantId: "${IDENTITY_TENANT}"        # The tenant ID of the key vault
   EOF
   

   Примечание.

   Если вы используете objectAlias вместо этого objectName, обновите скрипт YAML, чтобы он учитывал.

   Примечание.

   Чтобы SecretProviderClass обеспечить правильную работу, обязательно заполните Azure Key Vault секретами, ключами или сертификатами, прежде чем ссылаться на них в objects разделе.

8. Разверните пример pod с помощью kubectl apply команды и следующего скрипта YAML.

   cat <<EOF | kubectl apply -f -
   # This is a sample pod definition for using SecretProviderClass and workload identity to access your key vault
   kind: Pod
   apiVersion: v1
   metadata:
     name: busybox-secrets-store-inline-wi
     labels:
       azure.workload.identity/use: "true"
   spec:
     serviceAccountName: "workload-identity-sa"
     containers:
       - name: busybox
         image: registry.k8s.io/e2e-test-images/busybox:1.29-4
         command:
           - "/bin/sleep"
           - "10000"
         volumeMounts:
         - name: secrets-store01-inline
           mountPath: "/mnt/secrets-store"
           readOnly: true
     volumes:
       - name: secrets-store01-inline
         csi:
           driver: secrets-store.csi.k8s.io
           readOnly: true
           volumeAttributes:
             secretProviderClass: "azure-kvname-wi"
   EOF
   

Предварительные требования для драйвера CSI

• Прежде чем начать, выполните действия, описанные в разделе "Использование поставщика Azure Key Vault для драйвера CSI хранилища секретов" в кластере Служба Azure Kubernetes (AKS), чтобы включить драйвер CSI хранилища секретов Хранилища ключей Azure в кластере AKS.

Доступ с помощью управляемого удостоверения

Управляемый идентификатор Microsoft Entra — это удостоверение, которое администратор использует для проверки подлинности в других службах Azure. Управляемое удостоверение использует RBAC для федерации с внешними поставщиками удостоверений.

В этой модели безопасности вы можете предоставить доступ к ресурсам кластера участникам группы или клиентам, которым предоставлен доступ к управляемой роли. Роль проверяется, чтобы область доступа к keyvault и другим учетным данным. Если вы включили поставщик Azure Key Vault для драйвера CSI Хранилища секретов в кластере AKS, он создал удостоверение пользователя.

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

1. Доступ к хранилищу ключей с помощью az aks show команды и управляемого удостоверения, назначаемого пользователем, созданного надстройкой. Вы также должны получить идентификатор clientId, который вы будете использовать в последующих шагах при создании SecretProviderClass.

   az aks show --resource-group <resource-group> --name <cluster-name> --query addonProfiles.azureKeyvaultSecretsProvider.identity.objectId -o tsv
   az aks show --resource-group <resource-group> --name <cluster-name> --query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId -o tsv
   

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

   az identity create --resource-group <resource-group> --name <identity-name>
   az vmss identity assign --resource-group <resource-group> --name <agent-pool-vmss> --identities <identity-resource-id>
   az vm identity assign --resource-group <resource-group> --name <agent-pool-vm> --identities <identity-resource-id>
   
   az identity show --resource-group <resource-group> --name <identity-name> --query 'clientId' -o tsv
   

2. Создайте назначение ролей, которое предоставляет удостоверению разрешение на доступ к секретам хранилища ключей, ключам доступа и сертификатам с помощью az role assignment create команды.

   Внимание

   • Если хранилище ключей задано, --enable-rbac-authorization и вы используете key или certificate вводите ее, назначьте Key Vault Certificate User роль.
   • Если хранилище ключей задано и --enable-rbac-authorization используется secret тип, назначьте Key Vault Secrets User роль.
   • Если хранилище ключей не задано--enable-rbac-authorization, можно использовать az keyvault set-policy команду с --key-permissions get--certificate-permissions getпараметром или --secret-permissions get параметром для создания политики хранилища ключей для предоставления доступа к ключам, сертификатам или секретам. Например:

   az keyvault set-policy --name $KEYVAULT_NAME --key-permissions get --object-id $IDENTITY_OBJECT_ID
   

   export IDENTITY_OBJECT_ID="$(az identity show --resource-group <resource-group> --name <identity-name> --query 'principalId' -o tsv)"
   export KEYVAULT_SCOPE=$(az keyvault show --name <key-vault-name> --query id -o tsv)
   
   # Example command for key vault with RBAC enabled using `key` type
   az role assignment create --role "Key Vault Certificate User" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE
   

3. Создайте с помощью следующего SecretProviderClass YAML. Обязательно используйте собственные значения для userAssignedIdentityID, keyvaultNametenantIdи объектов для получения из хранилища ключей.

   # This is a SecretProviderClass example using user-assigned identity to access your key vault
   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: azure-kvname-user-msi
   spec:
     provider: azure
     parameters:
       usePodIdentity: "false"
       useVMManagedIdentity: "true"          # Set to true for using managed identity
       userAssignedIdentityID: <client-id>   # Set the clientID of the user-assigned managed identity to use
       keyvaultName: <key-vault-name>        # Set to the name of your key vault
       cloudName: ""                         # [OPTIONAL for Azure] if not provided, the Azure environment defaults to AzurePublicCloud
       objects:  |
         array:
           - |
             objectName: secret1
             objectType: secret              # object types: secret, key, or cert
             objectVersion: ""               # [OPTIONAL] object versions, default to latest if empty
           - |
             objectName: key1
             objectType: key
             objectVersion: ""
       tenantId: <tenant-id>                 # The tenant ID of the key vault
   

   Примечание.

   Если вы objectAlias используете вместо этого objectName, обязательно обновите скрипт YAML.

   Примечание.

   Чтобы SecretProviderClass обеспечить правильную работу, обязательно заполните Azure Key Vault секретами, ключами или сертификатами, прежде чем ссылаться на них в objects разделе.

4. Примените его к кластеру SecretProviderClass kubectl apply с помощью команды.

   kubectl apply -f secretproviderclass.yaml
   

5. Создайте модуль pod с помощью следующего YAML.

   # This is a sample pod definition for using SecretProviderClass and the user-assigned identity to access your key vault
   kind: Pod
   apiVersion: v1
   metadata:
     name: busybox-secrets-store-inline-user-msi
   spec:
     containers:
       - name: busybox
         image: registry.k8s.io/e2e-test-images/busybox:1.29-4
         command:
           - "/bin/sleep"
           - "10000"
         volumeMounts:
         - name: secrets-store01-inline
           mountPath: "/mnt/secrets-store"
           readOnly: true
     volumes:
       - name: secrets-store01-inline
         csi:
           driver: secrets-store.csi.k8s.io
           readOnly: true
           volumeAttributes:
             secretProviderClass: "azure-kvname-user-msi"
   

6. Примените pod к кластеру kubectl apply с помощью команды.

   kubectl apply -f pod.yaml
   

Проверка секретов Key Vault

После запуска модуля будет доступно подключенное содержимое по пути к тому, указанному в YAML развертывания. Используйте следующие команды, чтобы проверить секреты и распечатать секрет теста.

1. Отображение секретов, содержащихся в хранилище секретов, с помощью следующей команды.

   kubectl exec busybox-secrets-store-inline-user-msi -- ls /mnt/secrets-store/
   

2. Отображение секрета в хранилище с помощью следующей команды. В этом примере команды показан секрет ExampleSecretтеста.

   kubectl exec busybox-secrets-store-inline-user-msi -- cat /mnt/secrets-store/ExampleSecret
   

Получение сертификатов и ключей

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

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

Object	Возвращаемое значение	Возвращает всю цепочку сертификатов
key	Открытый ключ в формате "Расширенная почта конфиденциальности" (PEM).	Н/П
cert	Сертификат в формате PEM.	No
secret	Закрытый ключ и сертификат в формате PEM.	Да

Отключение надстройки в существующих кластерах

Примечание.

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

• Отключите поставщик Azure Key Vault для возможности драйвера CSI хранилища секретов в существующем кластере с помощью az aks disable-addons команды с надстройкой azure-keyvault-secrets-provider .

  az aks disable-addons --addons azure-keyvault-secrets-provider --resource-group myResourceGroup --name myAKSCluster
  

Примечание.

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

Следующие шаги

Из этой статьи вы узнали, как создать и предоставить удостоверение для доступа к Azure Key Vault. Интеграция соединителя служб помогает упростить конфигурацию подключения для рабочих нагрузок AKS и служб резервного копирования Azure. Он безопасно обрабатывает проверку подлинности и конфигурации сети и следует рекомендациям по подключению к службам Azure. Дополнительные сведения см. в статье "Использование поставщика Azure Key Vault для драйвера CSI хранилища секретов" в кластере AKS и вводные сведения о соединителе службы.

Если вы хотите настроить дополнительные параметры конфигурации или выполнить устранение неполадок, ознакомьтесь с параметрами конфигурации и ресурсами для поставщика Azure Key Vault с драйвером CSI хранилища секретов в AKS.