Связаться с намиПодключиться

Референсная архитектура для облачной инфраструктуры в изолированном режиме без доступа в интернет

Статья создана
Обновлена 15 октября 2024 г.

Одним из клиентских сценариев в Yandex Cloud является развертывание облачной инфраструктуры без доступа в интернет. Облачные ресурсы должны быть доступны только из собственной инфраструктуры клиента (on‑premise) и недоступны из интернет. Если для работы облачных ресурсов требуется сетевое взаимодействие с внешними ресурсами в интернет, то этот трафик должен проходить через собственную инфраструктуру клиента (например, межсетевые экраны), осуществляющую контроль доступа в интернет.

Раздел содержит рекомендации для реализации данного сценария.

Организация сетевого взаимодействия

Для данного сценария рекомендуемым способом организации сетевой IP-связности между ресурсами в собственной инфраструктуре клиента и облачными ресурсами в Yandex Cloud является подключение Cloud Interconnect:

  • С использованием выделенных физических каналов сетевое оборудование клиента подключается к оборудованию Yandex Cloud в точках присутствия напрямую с помощью кроссировки или через операторов связи.
  • Через подключения Cloud Interconnect возможна организация логических соединений как в облачные сети клиента, так и к сервисам Yandex Cloud (например, Object Storage).
  • Для обеспечения отказоустойчивости в предоставлении услуги Cloud Interconnect рекомендуется организовывать подключения на нескольких точках присутствия.
  • Подробные инструкции для подключения и управления услугой Cloud Interconnect приведены в документации.

Управление ресурсами и доступом

Ресурсная модель Yandex Cloud предполагает, что любой пользователь облака с правами editor или admin на ресурс может изменять его характеристики. В сценарии изолированной инфраструктуры возникает риск несанкционированного изменения характеристик ресурса, что нарушает модель угроз с точки зрения изоляции. Подобные события рекомендуется отслеживать через логи аудита сервиса (Audit Trails) и настройку оповещений в SIEM, однако существует и проактивный подход к контролю изменений защищаемой среды.

GitOps - подход к управлению инфраструктурой через формальное описание продуктовой инфраструктуры в коде (Infrastructure as Code) согласно модели угроз и применение изменений всех компонентов инфраструктуры через пул-реквесты в репозиторий исходного кода с последующим применением изменений в контексте сервисного аккаунта Yandex Cloud. Всем пользователям облака при этом должна быть назначена роль auditor или viewer на все сервисы продуктивной среды. Это позволяет нивелировать риски:

  • несанкционированного доступа к ресурсам и данным;
  • несанкционированного копирования или удаления ресурсов и данных администраторами облака;
  • несанкционированного изменения ресурсов, влекущего нарушение модели угроз (например назначение публичного IP-адреса на сетевой интерфейс или создание шлюза в сеть интернет);
  • любых неформализованных ("ручных") изменений с использованием повышенных привилегий.

Так как любое изменение подразумевает создание пул-реквеста в репозиторий исходного кода согласно принципам DevOps, то верификация и принятие решения о применении изменений зависит от ревьюеров (ответственных сотрудников). Изменения проверяются на корректность другими сотрудниками, исключая единоличное принятие решения автором пул-реквеста. При таком подходе вся история изменений ведется средствами системы управления репозиториями кода. На уровне организации Yandex Cloud у пользователей не должно быть административных привилегий, а все необходимые роли для различных сред следует выдавать через членство в группах субъектов.

Для управления репозиториями с кодом Yandex Cloud предоставляет сервис Yandex Managed Service for GitLab.

Требования к облачным сервисам

Ниже рассмотрены рекомендации по реализации данного сценария на примере основных сервисов Yandex Cloud:

По особенностям реализации доступа в интернет для других сервисов Yandex Cloud рекомендуется обращаться к документации соответствующего сервиса.

Compute Cloud

Виртуальные машины не должны иметь публичных IP-адресов.

Примечание

Способ проверки через консоль не показывает публичных IP-адресов остановленных ВМ. В таком случае рекомендуется использовать проверку через CLI.

  1. Откройте консоль управления в вашем браузере.
  2. Перейдите в нужный каталог.
  3. Перейдите в раздел Virtual Private Cloud / IP-адреса.
  4. Если Вы видите сообщение У вас пока нет публичных IP-адресов или зарезервированные публичные IP-адреса не используются для ВМ, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».

  1. Посмотрите доступные вам организации и зафиксируйте необходимый ID:

    yc organization-manager organization list

  2. Выполните команду для поиска всех ВМ с публичными IP-адресами:

    export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do VM_LIST=$(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.network_interfaces[].primary_v4_address.one_to_one_nat)' | jq -r '.id');
if [ -n "$VM_LIST" ]; then printf "FOLDER_ID: $FOLDER_ID\nVM_ID:\n$VM_LIST\n-----\n"; fi;
done;
done

  3. Если вывод команды пустой, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».

Инструкции и решения по выполнению:

  • Не выдавайте пользователям ролей, позволяющих создавать публичные IP-адреса для виртуальных машин. Роли, которые дают возможность назначения публичных IP-адресов для ВМ: admin, editor, vpc.admin, vpc.publicAdmin.
  • В случае наличия публичных IP-адресов на ВМ отвяжите их и, если это были статические IP-адреса, удалите их.

Virtual Private Cloud

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

  1. Откройте консоль управления в вашем браузере.
  2. Перейдите в нужный каталог.
  3. Перейдите в раздел Virtual Private Cloud / Шлюзы.
  4. Если Вы видите сообщение Нет ни одного шлюза, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».

  1. Посмотрите доступные вам организации и зафиксируйте необходимый ID:

    yc organization-manager organization list

  2. Выполните команду для поиска наличия NAT-шлюзов:

    export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do NAT_GW_LIST=$(yc vpc gateway list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.id)' | jq -r '.id');
if [ -n "$NAT_GW_LIST" ]; then printf "FOLDER_ID: $FOLDER_ID\nNAT_GW:\n$NAT_GW_LIST\n-----\n"; fi;
done;
done

  3. Если вывод команды пустой, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».

Инструкции и решения по выполнению:

  • Не выдавайте пользователям ролей, позволяющих создавать NAT-шлюзы. Роли, которые дают возможность создания NAT-шлюзов: admin, editor, vpc.gateways.editor, vpc.admin, vpc.publicAdmin.
  • В случае наличия NAT-шлюзов удалите их.

Network Load Balancer

Сетевой балансировщик Network Load Balancer можно развернуть в следующих вариантах:

  • Внешний балансировщик — создается по умолчанию. Имеет публичный IP-адрес и используется для обработки трафика из интернета.
  • Внутренний балансировщик — используется для обработки трафика внутри VPC. Имеет внутренний IP-адрес.

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

  1. Откройте консоль управления в вашем браузере.
  2. Перейдите в нужный каталог.
  3. Перейдите в раздел Network Load Balancer / Балансировщики.
  4. Если в списке отсутствуют балансировщики с типом EXTERNAL, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».

  1. Посмотрите доступные вам организации и зафиксируйте необходимый ID:

    yc organization-manager organization list

  2. Выполните команду для поиска всех внешних балансировщиков:

    export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do NLB_LIST=$(yc load-balancer network-load-balancer list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.type == "EXTERNAL")' | jq -r '.id');
if [ -n "$NLB_LIST" ]; then printf "FOLDER_ID: $FOLDER_ID\nNLB_ID:\n$NLB_LIST\n-----\n"; fi;
done;
done

  3. Если вывод команды пустой, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».

Инструкции и решения по выполнению:

  • Не выдавайте пользователям ролей, позволяющих создавать внешние балансировщики. Роли, которые дают возможность создания внешних балансировщиков: admin, editor, load-balancer.admin.
  • В случае наличия внешних балансировщиков удалите их.

Application Load Balancer

У L7-балансировщиков Application Load Balancer не должно быть публичных IP-адресов на обработчиках. Допускается использование внутренних IP-адресов на обработчиках.

  1. Откройте консоль управления в вашем браузере.
  2. Перейдите в нужный каталог.
  3. Перейдите в раздел Virtual Private Cloud / IP-адреса.
  4. Если Вы видите сообщение У вас пока нет публичных IP-адресов или зарезервированные публичные IP-адреса не используются для обработчиков L7-балансировщиков, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».

  1. Посмотрите доступные вам организации и зафиксируйте необходимый ID:

    yc organization-manager organization list

  2. Выполните команду для поиска всех L7-балансировщиков с публичными IP-адресами на обработчиках:

    export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do ALB_LIST=$(yc application-load-balancer load-balancer list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(has("listeners")) | select(.listeners[].endpoints[].addresses[].external_ipv4_address)' | jq -r '.id' );
if [ -n "$ALB_LIST" ]; then printf "FOLDER_ID: $FOLDER_ID\nALB_ID:\n$ALB_LIST\n-----\n" | sort -u; fi;
done;
done

  3. Если вывод команды пустой, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».

Инструкции и решения по выполнению:

  • Не выдавайте пользователям ролей, позволяющих назначать публичные IP-адреса на обработчики L7-балансировщиков. Роли, которые дают возможность назначения публичных IP-адресов на обработчики L7-балансировщиков: admin, editor, vpc.admin, vpc.publicAdmin.
  • В случае наличия публичных IP-адресов на обработчиках L7-балансировщиках удалите эти обработчики и, если это были статические IP-адреса, удалите их.

Managed Service for Kubernetes

У кластера и группы узлов Managed Service for Kubernetes не должно быть публичных IP-адресов. В облачной сети, где размещается кластер и группа узлов, не должно быть NAT-шлюзов. У сервисных аккаунтов для кластера не должно быть ролей на создание балансировщиков, имеющих доступ в интернет (см. пункт «Инструкции и решения по выполнению»).

Подробности по созданию и настройке кластера Managed Service for Kubernetes без доступа в интернет смотрите в практическом руководстве. В руководстве указаны минимальные роли, которые необходимо назначить сервисным аккаунтам для создания такого кластера.

Примечание

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

Примечание

Способ проверки через консоль не показывает публичных IP-адресов узлов остановленного кластера. В таком случае рекомендуется использовать проверку через CLI.

  1. Откройте консоль управления в вашем браузере.
  2. Перейдите в нужный каталог.
  3. Перейдите в раздел Managed Service for Kubernetes и выберите кластер.
  4. Если на вкладке Обзор поле Публичный IPv4 у кластера отсутствует, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».
  5. Перейдите в раздел Virtual Private Cloud / IP-адреса.
  6. Если Вы видите сообщение У вас пока нет публичных IP-адресов или зарезервированные публичные IP-адреса не используются для ВМ (узлов кластера) или L7-балансировщиков, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».
  7. Перейдите в раздел Virtual Private Cloud / Шлюзы.
  8. Если Вы видите сообщение Нет ни одного шлюза, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».
  9. Перейдите в раздел Network Load Balancer / Балансировщики.
  10. Если в списке отсутствуют балансировщики с типом EXTERNAL, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».

  1. Посмотрите доступные вам организации и зафиксируйте необходимый ID:

    yc organization-manager organization list

  2. Выполните команду для поиска всех кластеров с публичными адресами:

    export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id');
do CLUSTER_LIST=$(yc managed-kubernetes cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.master.endpoints.external_v4_endpoint)' | jq -r '.id');
if [ -n "$CLUSTER_LIST" ]; then printf "FOLDER_ID: $FOLDER_ID\nK8S_CLUSTER_ID:\n$CLUSTER_LIST\n-----\n"; fi;
done;
done

  3. Выполните команду для поиска всех групп узлов с публичными IP-адресами:

    export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do NODE_GROUP_LIST=$(yc managed-kubernetes node-group list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.node_template.network_interface_specs[].primary_v4_address_spec.one_to_one_nat_spec)' | jq -r '.id');
if [ -n "$NODE_GROUP_LIST" ]; then printf "FOLDER_ID: $FOLDER_ID\nNODE_GROUP:\n$NODE_GROUP_LIST\n-----\n"; fi;
done;
done

  4. Выполните команду для поиска наличия NAT-шлюзов:

    export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do NAT_GW_LIST=$(yc vpc gateway list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.id)' | jq -r '.id');
if [ -n "$NAT_GW_LIST" ]; then printf "FOLDER_ID: $FOLDER_ID\nNAT_GW:\n$NAT_GW_LIST\n-----\n"; fi;
done;
done

  5. Выполните команду для поиска наличия внешних балансировщиков NLB:

    export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do NLB_LIST=$(yc load-balancer network-load-balancer list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.type == "EXTERNAL")' | jq -r '.id');
if [ -n "$NLB_LIST" ]; then printf "FOLDER_ID: $FOLDER_ID\nNLB_ID:\n$NLB_LIST\n-----\n"; fi;
done;
done

  6. Выполните команду для поиска всех L7-балансировщиков с публичными IP-адресами на обработчиках:

    export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do ALB_LIST=$(yc application-load-balancer load-balancer list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(has("listeners")) | select(.listeners[].endpoints[].addresses[].external_ipv4_address)' | jq -r '.id' );
if [ -n "$ALB_LIST" ]; then printf "FOLDER_ID: $FOLDER_ID\nALB_ID:\n$ALB_LIST\n-----\n" | sort -u; fi;
done;
done

  7. Если выводы всех команд пустые, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».

Инструкции и решения по выполнению:

  • Не выдавайте сервисным аккаунтам для кластера Kubernetes ролей, позволяющих использовать публичные IP-адреса для кластера или группы узлов и создавать балансировщики, имеющие доступ в интернет. Роли, которые дают возможность создавать кластера с доступом в интернет: admin, editor, load-balancer.admin, vpc.admin, vpc.publicAdmin.
  • В случае наличия кластеров с публичными IP-адресами удалите их. Для таких кластеров нет возможности удалить непосредственно публичный IP-адрес. Перед удалением кластеров перенесите рабочую нагрузку на кластера Kubernetes без публичных IP-адресов.
  • В случае наличия групп узлов с публичными IP-адресами измените их, чтобы публичные IP-адреса не назначались узлам.
  • В случае наличия внешних балансировщиков для ресурсов Service удалите их.
  • В случае наличия публичных IP-адресов для Ingress-контроллеров Application Load Balancer удалите их.
  • Не выдавайте пользователям ролей, позволяющих создавать NAT-шлюзы. Роли, которые дают возможность создания NAT-шлюзов: admin, editor, vpc.gateways.editor, vpc.admin, vpc.publicAdmin.
  • В случае наличия NAT-шлюзов удалите их.

Managed Service for PostgreSQL

У хостов в кластере не должно быть публичного доступа.

Примечание

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

  1. Откройте консоль управления в вашем браузере.
  2. Перейдите в нужный каталог.
  3. Перейдите в раздел Managed Service for PostgreSQL. Зайдите в кластер и перейдите в раздел Хосты.
  4. Если в столбце Публичный доступ для всех хостов кластера указано значение Нет, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».

  1. Посмотрите доступные вам организации и зафиксируйте необходимый ID:

    yc organization-manager organization list

  2. Выполните команду для поиска всех хостов с публичными IP-адресами в кластерах:

    export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do for PG_CLUSTER_ID in $(yc managed-postgresql cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id');
do HOST_LIST=$(yc managed-postgresql hosts list --cluster-id=$PG_CLUSTER_ID --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.assign_public_ip)' | jq -r '.name' );
if [ -n "$HOST_LIST" ]; then printf "FOLDER_ID: $FOLDER_ID\nPG_CLUSTER_ID: $PG_CLUSTER_ID\nHOST_NAME:\n$HOST_LIST\n-----\n"; fi
done;
done;
done

  3. Если вывод команды пустой, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».

Инструкции и решения по выполнению:

  • Не выдавайте пользователям ролей, позволяющих настроить публичный доступ к хостам кластера. Роли, которые дают возможность настроить публичный доступ к хостам: admin, editor, vpc.admin, vpc.publicAdmin.
  • В случае наличия публичного доступа у хостов в кластере выключите для них опцию публичного доступа.

Managed Service for ClickHouse®

У хостов в кластере не должно быть публичного доступа.

Примечание

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

  1. Откройте консоль управления в вашем браузере.
  2. Перейдите в нужный каталог.
  3. Перейдите в раздел Managed Service for ClickHouse. Зайдите в кластер и перейдите в раздел Хосты.
  4. Если в столбце Публичный доступ для всех хостов кластера указано значение Нет, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».

  1. Посмотрите доступные вам организации и зафиксируйте необходимый ID:

    yc organization-manager organization list

  2. Выполните команду для поиска всех хостов с публичными IP-адресами в кластерах:

    export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do for CH_CLUSTER_ID in $(yc managed-clickhouse cluster list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id');
do HOST_LIST=$(yc managed-clickhouse hosts list --cluster-id=$CH_CLUSTER_ID --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.assign_public_ip)' | jq -r '.name' );
if [ -n "$HOST_LIST" ]; then printf "FOLDER_ID: $FOLDER_ID\nCH_CLUSTER_ID: $CH_CLUSTER_ID\nHOST_NAME:\n$HOST_LIST\n-----\n"; fi
done;
done;
done

  3. Если вывод команды пустой, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».

Инструкции и решения по выполнению:

  • Не выдавайте пользователям ролей, позволяющих настроить публичный доступ к хостам кластера. Роли, которые дают возможность настроить публичный доступ к хостам: admin, editor, vpc.admin, vpc.publicAdmin.
  • В случае наличия публичного доступа у хостов в кластере выключите для них опцию публичного доступа.

Cloud Functions и Serverless Containers

В облачной инфраструктуре не должно быть функций или контейнеров.

По умолчанию функция или контейнер запускается в изолированной IP-сети с включенным NAT-шлюзом. Из функции или контейнера доступны публичные IPv4-адреса. В настройках функции или контейнера можно указать облачную сеть. Тогда функция будет иметь доступ не только в интернет, но и к пользовательским ресурсам, которые находятся в указанной VPC, например базам данным, виртуальным машинам и другим ресурсам.

  1. Откройте консоль управления в вашем браузере.
  2. Перейдите в нужный каталог.
  3. Перейдите в раздел Cloud Functions.
  4. Если Вы видите сообщение Создайте вашу первую функцию, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».
  5. Перейдите в раздел Serverless Containers.
  6. Если Вы видите сообщение Создайте ваш первый контейнер, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».

  1. Посмотрите доступные вам организации и зафиксируйте необходимый ID:

    yc organization-manager organization list

  2. Выполните команду для поиска всех функций:

    export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do FUNC_LIST=$(yc serverless function list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id');
if [ -n "$FUNC_LIST" ]; then printf "FOLDER_ID: $FOLDER_ID\nFUNCTION_ID:\n$FUNC_LIST\n-----\n"; fi;
done;
done

  3. Если вывод команды пустой, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».

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

    export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do CONT_LIST=$(yc serverless containers list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id');
if [ -n "$CONT_LIST" ]; then printf "FOLDER_ID: $FOLDER_ID\nCONTAINER_ID:\n$CONT_LIST\n-----\n"; fi;
done;
done

  5. Если вывод команды пустой, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».

Инструкции и решения по выполнению:

  • Не выдавайте пользователям ролей, позволяющих создавать функции и контейнеры. Роли, которые дают возможность создания функций: admin, editor, functions.admin, functions.editor. Роли, которые дают возможность создания контейнеров: admin, editor, serverless-containers.admin, serverless-containers.editor.
  • В случае наличия функций или контейнеров удалите функции или контейнеры.
Предыдущая
Безопасность Kubernetes
Следующая
Все разделы на одной странице