Как использовать Terraform для настройки проверенного доступа AWS с поставщиком OIDC Google

В этой записи блога я познакомлю вас с Подтвержденный доступ AWS и Terraform.

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

Мы будем использовать Google AuthN в качестве поставщика доверия пользователей OIDC (OpenID Connect) вместо центра идентификации IAM, поскольку некоторые пользователи этого не делают. не имеют к нему доступа или не могут изменить разрешения своего центра идентификации IAM. Кроме того, после настройки конечной точки проверенного доступа мы настроим разрешения AuthZ с помощью Язык конфигурации Cedar.

По умолчанию я предполагаю, что у вас уже есть какой-либо частный сервис EC2/ECS/EKS (скрытый через частный ALB или нет), к которому вы хотите получить доступ без использования VPN. В этой статье мы не будем рассматривать процесс развертывания такого сервиса. Кроме того, я предполагаю, что вы знакомы с AWS Certificate Manager и знаете, как использовать его для выпуска и хранения сертификатов TLS.

Не волнуйтесь, если вы новичок в Terraform или AWS Verified Access; Я проведу вас через все шаг за шагом, включая весь код. Приготовьтесь к захватывающему обучающему приключению!

Предварительные условия

• Базовое понимание AWS, VPC< /a> и Terraform
• учетная запись AWS с необходимыми разрешениями для создания VPC, подсетей, подтвержденного доступа и т. д.
>
• Настроен aws cli для указания в ваш аккаунт AWS
• Настроен Terraform/OpenTofu
• Настроен аккаунт Google Cloud
• По крайней мере одна частная служба EC2/ECS/EKS с балансировщиком нагрузки приложения/сети или интерфейсом ENI.

:::информация В этой статье использовался Terraform v1.5.7. Это последняя версия Terraform, лицензируемая в соответствии с Общественной лицензией Mozilla v2.0 (MPL 2.0). Все последующие версии были перенесены на лицензию Business Source (BSL) v1.1. Если вы создаете что-то коммерческое на основе Terraform, не переходите на более позднюю версию; вместо этого перейдите на OpenTofu.

:::

:::совет Если вам нужно управлять несколькими версиями Terraform или OpenTofu, используйте tfenv/tofuenv инструменты для быстрого переключения между ними.

:::

Что такое подтвержденный доступ AWS?

Подтвержденный доступ AWS – это сервис, который может обеспечить безопасный доступ к вашим приложениям без необходимости использования виртуальной частной сети (VPN). Подтвержденный доступ оценивает каждый запрос приложения и помогает гарантировать, что пользователи смогут получить доступ к каждому приложению только в том случае, если они соответствуют указанным требованиям безопасности.

Настройка приложения Google OAuth

Для OIDC AuthN поставщику доверия AWS требуется набор параметров конфигурации, например Идентификатор клиента или Секрет клиента. К сожалению, AWS не предоставляет руководства по настройке Google OAuth и получению этих значений. Итак, позвольте мне рассказать вам об этом шаг за шагом.

Настройка экрана согласия OAuth

1. Перейдите в консоль Google Cloud → API & Сервисы → Экран согласия OAuth
<ли>

Выберите тип приложения.

<ли>

Внутренний: если вы хотите использовать экран согласия OAuth только для пользователей внутри вашей организации Google.

2. Внешний: если вы хотите использовать экран согласия OAuth для любых пользователей Google.
3. Нажмите кнопку «Создать».
<ли>

Заполните поля «Название приложения», «Электронная почта службы поддержки пользователей», «Контактная информация разработчика» и «Авторизованные домены».



5. Все последующие экраны можно пропустить; после всех нажмите "Сохранить".

Создайте учетные данные OIDC

1. Перейдите в облачную консоль Google → API & Услуги → Учетные данные
2. Нажмите «СОЗДАТЬ УЧЕТНЫЕ ДАННЫЕ» → «Идентификатор клиента OAuth».
3. Тип приложения должен быть «Веб-приложение».
4. Заполните форму, как показано на скриншоте; В моем случае я буду использовать доменное имя kvendingoldo.dev.referrs.me в качестве имени конечной точки AWS Verified Access. Кроме того, вам необходимо добавить его в разделы Авторизованные источники JavaScript и Авторизованные URI перенаправления.

:::совет Помните, что раздел URI авторизованного перенаправления должен включать второй URI: https://your_domain>/oauth2/idpresponse. Google AuthN не будет работать должным образом без второго URI.

:::



5. После нажатия кнопки «Сохранить» вы увидите «Клиент OAuth создан». Идентификатор клиента и Секрет клиента необходимо скопировать. В будущем они будут использоваться поставщиком доверия AWS Verified Access.



Инфраструктура AWS

Теперь пришло время использовать Terraform для создания ресурсов AWS Verified Access. Во-первых, давайте взглянем на нашу структуру каталогов:

.
├── 01-data.tf
├── 01-meta.tf
├── 03-main.tf
└── 05-variables.tf

Terraform по умолчанию не обеспечивает жесткую структуру проекта, и все ресурсы можно создать в одном файле, например main.tf. Мне это не нравится, и я рекомендую вам использовать следующий макет для ваших ресурсов:

| Имя файла | Ресурсы | |----|----| | 01-data.tf | Ресурсы данных | | 01-meta.tf | Блок конфигурации Terraform и конфигурация провайдеров | | 03-main.tf | Общие облачные ресурсы, которые вы собираетесь создать | | 03-modules.tf | Определение модулей Terraform, которые вы собираетесь использовать | | 05-variables.tf | Переменные терраформирования | | 06-outputs.tf | Результаты терраформирования |

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

01-meta.tf

provider "aws" {
  region = "us-east-2"
}

terraform {
  required_version = "1.5.7"

  required_providers {
    aws = ">= 5.0.0"
  }
}

Как видите, в этом файле есть два блока конфигурации:

• terraform: специальный тип блока конфигурации используется для настройки некоторых вариантов поведения Сам Terraform, например требование наличия минимальной версии Terraform для применения вашей конфигурации.
• При работе с кодом Terraform рекомендуется указывать версию используемых вами поставщиков. Явно определяя версию, вы гарантируете, что ваш код будет последовательно создаваться и тестироваться, что снижает риск проблем совместимости. Если версия не указана, Terraform получит самую последнюю версию, что может привести к неожиданному поведению и потенциальным проблемам совместимости. В моем случае я установил >= 5.0.0. версию, достаточную для примера.
Блок провайдера
• aws с регионом по умолчанию us-east2.

01-data.tf

data "aws_route53_zone" "main" {
  zone_id = var.r53_zone_id
}

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

В рамках вашей инфраструктуры мы создадим запись Route53 для конечной точки проверенного доступа, поэтому дополнительная информация о нашей DNS-зоне Route53 чрезвычайно полезна. В результате мы определяем источник данных aws_route53_zone, который предоставит нам обширную информацию о зоне Route53 исключительно на основе идентификатора зоны.

03-main.tf

locals {
  tags = merge(var.tags, {
    Name : var.svc_name
  })
}

resource "aws_verifiedaccess_instance" "main" {
  count = var.enable_va ? 1 : 0

  tags = local.tags
}

resource "aws_verifiedaccess_trust_provider" "main" {
  count = var.enable_va && var.va_trustprovider_id == null ? 1 : 0

  description = format("Verified Access Trust provider for %s app", var.svc_name)

  policy_reference_name    = replace(format("%s-%s", var.env_abbr, var.svc_name), "-", "_")
  trust_provider_type      = "user"
  user_trust_provider_type = var.va_user_trust_provider_type

  dynamic "oidc_options" {
    for_each = var.va_user_trust_provider_type == "oidc" ? [1] : []
    content {
      authorization_endpoint = var.va_authorization_endpoint
      client_id              = var.va_client_id
      client_secret          = var.va_client_secret
      issuer                 = var.va_issuer
      scope                  = var.va_scope
      token_endpoint         = var.va_token_endpoint
      user_info_endpoint     = var.va_user_info_endpoint
    }
  }

  tags = local.tags
}

resource "aws_verifiedaccess_instance_trust_provider_attachment" "main" {
  count = var.enable_va ? 1 : 0

  verifiedaccess_instance_id       = aws_verifiedaccess_instance.main[0].id
  verifiedaccess_trust_provider_id = var.va_trustprovider_id == null ? aws_verifiedaccess_trust_provider.main[0].id : var.va_trustprovider_id
}

resource "aws_verifiedaccess_group" "main" {
  count = var.enable_va ? 1 : 0

  verifiedaccess_instance_id = aws_verifiedaccess_instance.main[0].id
  policy_document            = var.va_group_policy_document

  tags = local.tags

  depends_on = [
    aws_verifiedaccess_instance_trust_provider_attachment.main[0]
  ]
}

resource "aws_verifiedaccess_endpoint" "main" {
  count = var.enable_va ? 1 : 0

  application_domain     = format("%s.%s", var.r53_va_record, data.aws_route53_zone.main.name)
  attachment_type        = "vpc"
  domain_certificate_arn = var.va_domain_cert_arn
  endpoint_domain_prefix = substr(format("%s-%s", var.env_abbr, var.svc_name), 0, 19)
  endpoint_type          = "load-balancer"
  load_balancer_options {
    load_balancer_arn = var.lb_arn
    port              = var.lb_port
    protocol          = var.lb_protocol
    subnet_ids        = var.subnet_ids
  }
  security_group_ids       = var.sg_ids
  verified_access_group_id = aws_verifiedaccess_group.main[0].id
}

resource "aws_route53_record" "va" {
  count = var.enable_va ? 1 : 0

  zone_id = var.r53_zone_id
  name    = var.r53_va_record
  type    = "CNAME"
  ttl     = 60

  records = [
    aws_verifiedaccess_endpoint.main[0].endpoint_domain
  ]
}

#
# Logging
#
resource "aws_verifiedaccess_instance_logging_configuration" "main" {
  count = var.enable_va && var.enable_va_logging ? 1 : 0

  verifiedaccess_instance_id = aws_verifiedaccess_instance.main[0].id

  access_logs {
    include_trust_context = var.va_log_include_trust_context
    log_version           = var.va_log_version


    dynamic "cloudwatch_logs" {
      for_each = var.va_log_cloudwatch_enabled ? [1] : []
      content {
        enabled   = var.va_log_cloudwatch_enabled
        log_group = var.va_log_cloudwatch_log_group_id
      }
    }

    dynamic "kinesis_data_firehose" {
      for_each = var.va_log_kinesis_enabled ? [1] : []
      content {
        enabled         = var.va_log_kinesis_enabled
        delivery_stream = var.va_log_kinesis_delivery_stream_name

      }
    }

    dynamic "s3" {
      for_each = var.va_log_s3_enabled ? [1] : []
      content {
        enabled     = var.va_log_s3_enabled
        bucket_name = var.va_log_s3_bucket_name

      }
    }
  }
}

Это самый важный файл, поскольку он содержит все необходимые ресурсы AWS Verified Access. Давайте рассмотрим каждый из них и некоторые хитрости, которые вы можете увидеть в предоставленном фрагменте кода.

Многие ресурсы имеют Terraform count на основе следующего правила: count = var.enable_va? 1:0. Этот метод полезен, когда вам нужно быстро включить или отключить часть вашей инфраструктуры Terraform. В больших масштабах у вас может быть много флагов функций, например var.enable_va.

Кроме того, при обсуждении методов, продемонстрированных во фрагменте, важно выделить преобразование переменной var.tags в локальная переменная local.tags. Как вы можете видеть в верхней части этого файла, мы объединили var.tag с тегом Name для получения новой карты, которая хранится внутри local. .теги. Это полезно, поскольку без него все ресурсы в пользовательском интерфейсе консоли AWS будут иметь пустое имя.

Давайте теперь подробнее рассмотрим каждый ресурс AWS.

==aws_verifiedaccess_instance==

Экземпляр AWS Verified Access – это ресурс AWS, который помогает вам организовать поставщиков доверия и группы проверенного доступа. За исключением тегов, это простой ресурс Terraform, не требующий каких-либо дополнительных параметров конфигурации.

==aws_verifiedaccess_trust_provider==

Поставщик доверия – это сервис AWS, который отправляет информацию о пользователях и устройствах в AWS Verified Access. Эта информация называется контекстом доверия. Он может включать атрибуты, основанные на личности пользователя, например адрес электронной почты или членство в "торговой" организации, или информацию об устройстве, например установленные исправления безопасности или версию антивирусного программного обеспечения.

Подтвержденный доступ поддерживает следующие категории провайдеров доверия:

• Идентификация пользователя – служба поставщика удостоверений (IdP), которая хранит цифровые удостоверения пользователей и управляет ими.
• Управление устройствами – система управления такими устройствами, как ноутбуки, планшеты и смартфоны.

В нашем случае мы используем поставщика идентификации пользователя (trust_provider_type = "user") вместе с конфигурацией OIDC (oidc_options).

==aws_verifiedaccess_instance_trust_provider_attachment==

Эти ресурсы прикрепляют экземпляр проверенного доступа к поставщику доверия проверенного доступа.

==aws_verifiedaccess_group==

Это ресурс для управления группой проверенного доступа. Группа проверенного доступа AWS — это совокупность конечных точек проверенного доступа и политики проверенного доступа на уровне группы. Каждая конечная точка в группе разделяет политику проверенного доступа.

Вы можете использовать группы для сбора конечных точек, имеющих общие требования к безопасности. Это может помочь упростить администрирование политик за счет использования одной политики (опция policy_document. О настройке политик мы поговорим позже) для обеспечения безопасности нескольких приложений.

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

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

==aws_verifiedaccess_endpoint==

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

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

endpoint_type          = "load-balancer"
load_balancer_options {
  load_balancer_arn = var.lb_arn
  port              = var.lb_port
  protocol          = var.lb_protocol
  subnet_ids        = var.subnet_ids
}

Важно подчеркнуть, что aws_verifiedaccess_endpoint имеет правильно настроенный параметр domain_certificate_arn, который должен указывать на действительный сертификат TLS, хранящийся в AWS Certificate Manager. Помните, что сертификат должен соответствовать записи домена Route53, которая будет создана для конечной точки проверенного доступа AWS.

:::совет Для выдачи можно использовать Менеджер сертификатов AWS. купленный сертификат, но я предпочитаю бесплатные сертификаты Let’s Encrypt. AWS изначально не поддерживает интеграцию Let's Encrypt и диспетчера сертификатов, поэтому я создал AWS Lambda, которая автоматически выдает и обновляет сертификаты TLS. Исходники и документацию этой Lambda можно найти по адресу https://github.com/kvendingoldo/aws-letsencrypt. -лямбда.

:::

ALB/NLB — не единственный метод предоставления услуги через проверенную конечную точку доступа. Вы также можете предоставить службу за пределами частной сети, используя любой частный интерфейс ENI, например интерфейс ENI EC2, через конечную точку проверенного доступа.

  endpoint_type          = "network-interface"
  network_interface_options {
    network_interface_id = aws_network_interface.example.id
    port                 = 443
    protocol             = "https"
  }

==aws_route53_record==

Этот ресурс создает ресурс записи Route53 для конечной точки проверенного доступа. Поскольку конечная точка проверенного доступа имеет собственное DNS-имя; тип нашей записи (kvendingoldo.dev.referrs.me) должен быть CNAME.

==aws_verifiedaccess_instance_logging_configuration==

Этот ресурс управляет конфигурацией ведения журнала проверенного доступа. Я настоятельно рекомендую включить этот ресурс с помощью функционального флага var.enable_va_logging во время тестирования проверенного доступа. Для меня было достаточно использовать только журналы CloudWatch для поиска проблем в правилах Cedar, но вы также можете настроить источники S3 или Kinesis для отправки журналов из вашего проверенного экземпляра доступа.

Если во время тестирования у вас возникнут проблемы с правилами, вы увидите в своих журналах что-то вроде этого: n

    "activity_id": "2",
    "activity_name": "Access Deny",
    "actor": null,
    "category_name": "Audit Activity",
    "category_uid": "3",
    "class_name": "Access Activity",
    "class_uid": "3006",
    "data": null,
    "device": null,
    "duration": "0.0",
    "end_time": "1704880589864",
    "time": "1704880589864",
    "http_request": {
        "http_method": "GET",
        "url": {
            "hostname": "3.100.226.13",
            "path": "/version",
            "port": 443,
            "scheme": "https",
            "text": "https://3.100.226.13:443/version"
        },
        "user_agent": "Mozilla/5.0 zgrab/0.x",
        "version": "HTTP/1.1"
    },
    "http_response": {
        "code": 302
    },
    "message": "",
    "metadata": {
        "uid": "Root=1-659e69cd-2832fc7d4af907443fce29dd",
        "logged_time": 1704880985929,
        "version": "1.0.0-rc.2",
        "product": {
            "name": "Verified Access",
            "vendor_name": "AWS"
        }
    },
    "ref_time": "2024-01-10T09:56:29.864879Z",
    "proxy": {
        "ip": "3.133.226.13",
        "port": 443,
        "svc_name": "Verified Access",
        "uid": "vai-0de4109b1cc38ecd4"
    },
    "severity": "Informational",
    "severity_id": "1",
    "src_endpoint": {
        "ip": "162.243.138.37",
        "port": 50388
    },
    "start_time": "1704880589864",
    "status_code": "200",
    "status_detail": "Authentication Denied",
    "status_id": "2",
    "status": "Failure",
    "type_uid": "300602",
    "type_name": "Access Activity: Access Deny",
    "unmapped": null
}

Кроме того, я рекомендую создать группу журналов Cloudwatch с помощью Terraform и других ресурсов, что можно сделать с помощью следующего кода:

resource "aws_cloudwatch_log_group" "main" {
  name              = "my_va_loggroup_for_testing"
  retention_in_days = 10
  tags              = var.tags
}

05-variables.tf

Я хотел бы поговорить о переменных Google OIDC, прежде чем мы перейдем к переменным Terraform для наших ресурсов. Мне не удалось найти никакой документации о правильном наборе этих переменных, и по этой причине мне пришлось получить их на сайте . https://accounts.google.com/.well-known/openid-configuration.

:::совет Используйте https://accounts.google.com/.well-known/openid-configuration в качестве источник истины для параметров конфигурации Google AuthN.

:::

Это файл переменных Terraform нашей инфраструктуры:

#
# Common variables
#
variable "svc_name" {
  type    = string
  default = "kvendingoldo-app"
}
variable "env_abbr" {
  type    = string
  default = "dev01"
}
variable "tags" {
  default = {
    automation : "terraform"
    data_classification : "internal"
    owner : "Alexander Sharov"
  }
}

#
# Network
#
variable "subnet_ids" {
  description = "A list of subnet ids where verified access endpoint will be placed"
  type        = list(string)
}
variable "sg_ids" {
  description = "List of the the security groups IDs to associate with the Verified Access endpoint"
  type        = list(string)
}
variable "lb_arn" {
  description = "The ARN of the load balancer that will be used for the Verified Access endpoint"
  type        = string
}
variable "lb_port" {
  description = "The load balancer port that will be used for the Verified Access endpoint"
  type        = string
  default     = 80
}
variable "lb_protocol" {
  description = "The load balancer protocol that will be used for the Verified Access endpoint"
  type        = string
  default     = "http"
}

#
# Verified Access Common
#
variable "enable_va" {
  default = true
}
variable "enable_va_logging" {
  default = false
}
variable "va_domain_cert_arn" {
  default = null
}
variable "va_group_policy_document" {
  description = "The policy document that is associated with this resource"
  type        = string
  default     = null
}

#
# Verified Access Trust provider
#
variable "va_trustprovider_id" {
  default = null
}
variable "va_user_trust_provider_type" {
  description = "The type of user-based trust provider."
  type        = string
  default     = "oidc"
}

#
# Verified Access logging
#
variable "va_log_include_trust_context" {
  default = true
}
variable "va_log_version" {
  default = "ocsf-1.0.0-rc.2"
}

variable "va_log_cloudwatch_enabled" {
  default = false
}
variable "va_log_cloudwatch_log_group_id" {
  default = ""
}

variable "va_log_kinesis_enabled" {
  default = false
}
variable "va_log_kinesis_delivery_stream_name" {
  default = null
}

variable "va_log_s3_enabled" {
  default = false
}
variable "va_log_s3_bucket_name" {
  default = null
}

#
# Verified Access Trust provider OIDC Settings
#
variable "va_authorization_endpoint" {
  description = "The OIDC authorization endpoint"
  type        = string
  default     = "https://accounts.google.com/o/oauth2/v2/auth"
}
variable "va_client_id" {
  description = "The client identifier"
  type        = string
}
variable "va_client_secret" {
  description = "The client secret"
  type        = string
}
variable "va_issuer" {
  description = "The OIDC issuer"
  type        = string
  default     = "https://accounts.google.com"
}
variable "va_scope" {
  description = "OpenID Connect (OIDC) scopes are used by an application during authentication to authorize access to details of a user."
  type        = string
  default     = "openid email profile"
}
variable "va_token_endpoint" {
  description = "The OIDC token endpoint"
  type        = string
  default     = "https://oauth2.googleapis.com/token"
}
variable "va_user_info_endpoint" {
  description = "The OIDC user info endpoint"
  type        = string
  default     = "https://openidconnect.googleapis.com/v1/userinfo"
}

#
# Route53
#
variable "r53_zone_id" {
  default = ""
}
variable "r53_va_record" {
  default = "kvendingoldo"
}

Давайте обсудим лишь некоторые переменные, которые могут вызвать вопросы

| Имя переменной | Описание | |----|----| | va_domain_cert_arn | ARN сертификата, хранящегося в диспетчере сертификатов AWS. Его следует создать до предоставления инфраструктуры. | | va_group_policy_document | Документ политики AuthZ. Мы рассмотрим эту переменную более подробно в следующем разделе. | | va_trustprovider_id | Идентификатор существующего доверенного поставщика. Если он не пуст, новый поставщик доверия не будет создан. | | va_client_id | Идентификатор клиента Google OAuth | | va_client_secret | Секретный идентификатор Google OAuth | | r53_zone_id | Идентификатор зоны Route53. В моем случае это идентификатор зоны dev.referrs.me, которая управляется через AWS Route53. | | r53_va_record | Имя записи внутри зоны r53_zone_id. В моем случае значением является kvendingoldo |

Политики AuthZ через правила Cedar

Наконец, после того как мы настроили нашу инфраструктуру и AuthN, мы можем настроить Политики AuthZ. Для таких политик группа проверенного доступа AWS использует язык конфигурации Cedar. Например:

permit(principal, action, resource)
when {
    // Returns true if the email ends in "@example.com"
    context.identity.email like "*@example.com" &&
    // Returns true if the user is part of the "finance" group
    context.identity.groups.contains("finance")
};

В моем случае я хотел бы ограничить доступ к службе в рамках проверенной конечной точки доступа для всех пользователей с адресом электронной почты *@referrs.me. Правило будет следующим:

permit(principal,action,resource)
when {
    context.dev01_kvendingoldo_app.email like "*@referrs.me"

};

Обратите внимание на dev01_kvendingoldo_app. Эта переменная настроена внутри ресурса aws_verifiedaccess_trust_provider Terraform, свойство policy_reference_name:

policy_reference_name    = replace(format("%s-%s", var.env_abbr, var.svc_name), "-", "_")

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

variable "va_group_policy_document" {
  description = "The policy document that is associated with this resource"
  type        = string
  default     = <<-EOT
permit(principal,action,resource)
when {
  context.dev01_kvendingoldo_app.email like "*@referrs.me"
};
EOT
}

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

Заключение

В этом сообщении блога я продемонстрировал, как использовать Terraform для создания инфраструктуры проверенного доступа для любого частного интерфейса ALB/NLB или ENI. Вы можете использовать ту же инфраструктуру, если вам нужен простой безопасный доступ к вашему сервису на основе Google AuthN без настройки VPN.

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

Следите за обновлениями, в которых мы много поговорим об инфраструктуре Terraform.

Ссылки

• документация по подтвержденному доступу AWS
• документация Terraform, Документация поставщика AWS Terraform, документация tofuenv для управления несколькими версиями CLI OpenTofu и Документация Terraform Документация CLI для автоматического создания документации модуля Terraform.
• документация OpenTofu.
• Репозиторий TofuEnv.
• aws-letsencrypt-lambda репозиторий.
• Ознакомление с политиками проверенного доступа AWS.
• Язык конфигурации Cedar< /а>.

н

---

Оригинал