Seem to require to reference a gateway subnet with name GatewaySubnet

[yunkon-kim]

Trial

• Try to use the name "my-azure-subnet-2" instead of "GatewaySubnet"
  • Considering the subnet injection situation, it was necessary to check whether the subnet name affects the VPN tunneling process.
  • But, it seems to require to reference a gateway subnet with the name GatewaySubnet...

resource "azurerm_subnet" "my-azure-gw-subnet" {
  name                 = "my-azure-subnet-2"
  resource_group_name  = azurerm_resource_group.my-azure-resource-group.name
  virtual_network_name = azurerm_virtual_network.my-azure-vnet.name
  address_prefixes     = ["192.168.129.0/24"]
}

Result - failed with the following errors

╷
│ Error: expected ip_configuration.0.subnet_id to reference a gateway subnet with name GatewaySubnet
│ 
│   with azurerm_virtual_network_gateway.my-azure-vpn-gateway,
│   on azure-networking.tf line 60, in resource "azurerm_virtual_network_gateway" "my-azure-vpn-gateway":
│   60:     subnet_id                     = azurerm_subnet.my-azure-gw-subnet.id
│ 
╵
╷
│ Error: expected ip_configuration.1.subnet_id to reference a gateway subnet with name GatewaySubnet
│ 
│   with azurerm_virtual_network_gateway.my-azure-vpn-gateway,
│   on azure-networking.tf line 67, in resource "azurerm_virtual_network_gateway" "my-azure-vpn-gateway":
│   67:     subnet_id                     = azurerm_subnet.my-azure-gw-subnet.id
│ 
╵

[yunkon-kim]

Background

Azure의 경우 CSP간에 VPN tunnel을 구성할 때 GatewaySubnet을 필요로 합니다.

GatewaySubnet은 가상 네트워크 게이트웨이(예, VPN Gateway) 및 서비스에서 사용하는 IP 주소와 관련된 서브넷 입니다.
(see 게이트웨이 서브넷)

참고 - 테스트 결과 GatewaySubnet에 VM을 생성할 수는 없었습니다.

GatewaySubnet 생성 및 관리 방안

방안) GatewaySubnet 을 위한 CIDR block 정도를 입력 받아 Tofu에서 생성 및 관리하는 방안을 고려하고 있습니다.
이유)

• 특수한(?) 자원으로 Spider에서 추상화 대상에 포함되지 않을 것으로 보임
• 따라서 Tumblebug의 통합 운용 및 관리 대상이 아닐 것으로 판단

@powerkimhub @seokho-son
위 방안에 대해 검토 및 의견을 부탁드립니다.

[seokho-son]

@yunkon-kim 정보 공유 감사합니다.

해당 자원은 VPN 연동을 위해서만 활용하는 Azure만의 방법(자체 생성하는 관리형 게이트웨이 VM을 통해 처리)이니,
내부 시스템에서 자동으로 생성/삭제를 진행하면, TB 차원에서는 복잡성이 낮아지는 장점이 있을 것 같습니다.

다만, 이렇게 처리하게 되는 경우, 아무래도 댕글링되는 자원들이 남을 수 있어서 내부 시스템(TF)의 관리가 복잡해질 수도 있겠네요.

현재는 PoC 단계이므로, 말씀해주신 방향대로 추진하면 좋을 것 같고,
TB에서는 미리 대응해둘 만한 효율적인 방법들을 고민해보도록 하겠습니다. (필요하다면 GatewaySubnet 을 직접 생성 및 관리하는 방법 등)

@powerkimhub
cloud-barista/cb-tumblebug#1452 (comment) 와도 관련이 있습니다만,
처리해야 하는 자원의 종류가 많아짐에 따라, CSP가 명시적으로 네이밍을 요구하는 경우들도 많이 발생할 것 같습니다.

• TB가 SP에 자원생성 요청시, TB에서 생성 요청한 자원의 ID(또는 명칭)가 CSP 사용자 요청 ID(또는 명칭)에 직접 반영될 수 있도록
  값을 명시하여 요청할 수 있도록 처리해주시면 감사하겠습니다. (이 경우, ID 네이밍 제약은 고려하지 않아도 괜찮습니다.)

[yunkon-kim]

Ref. Sample design for multi-cloud network configuration

[powerkimhub]

@seokho-son

• TB가 SP에 자원생성 요청시, TB에서 생성 요청한 자원의 ID(또는 명칭)가 CSP 사용자 요청 ID(또는 명칭)에 직접 반영될 수 있도록
  값을 명시하여 요청할 수 있도록 처리해주시면 감사하겠습니다. (이 경우, ID 네이밍 제약은 고려하지 않아도 괜찮습니다.)

• #1133 이슈에서 고민해보도록 하겠습니다.

[powerkimhub]

@seokho-son (cc: @yunkon-kim )

• 사용자가 설정한 NameID를 변형하지 않고 그대로 CSP에 전달할 수 있는 설정이 추가되었습니다.
• v0.8.15부터 제공
• cf) ID Transformation ON/OFF Guide

[seokho-son]

@powerkimhub 이슈 대응 감사합니다.

API request body에

   "ConnectionName": "aws-config01",
   "ID_TRANSFORM_MODE" : "ON",         # <==================
   "ReqInfo": {
     "Name": "spider-disk-03",
     "Zone": "us-east-2a",
     "DiskType": "default",
     "DiskSize": "default"
   }
 }'

혹시 수정 가능하시다면,
"ID_TRANSFORM_MODE" : "ON" 의 필드 및 값 표현 방식이
기존 request body의 field 들과 다소 달라서, 표현 방식을 비슷하게 처리해주시면 좋을 것 같습니다.

[powerkimhub]

@seokho-son

성격이 좀 다른 변수라 다르게 해봤었는데
다음처럼 반영하지요.

• AS-IS: ID_TRANSFORM_MODE
• TO-BE: IDTransformMode

[seokho-son]

@powerkimhub 넵, 보통 API의 경우 공통적인 함수로 자동으로 처리(json 등)하는 경우가 많다보니, 일관성이 있는 것을 더 선호하는 경향이 있는 것 같습니다.

향후 수정해주시면, IDTransformMode: on 을 활용하겠습니다.

[powerkimhub]

@seokho-son

• 반영했습니다.
• 동일 버전(v0.8.15) 사용하시면 되겠습니다.