@seokho-son @yunkon-kim

• 현 PR은 기존 운영 자원들의 자동 등록을 위한 개선 필요 사항이라고 생각됩니다.
• VPC Name 없는 SG 등록이 임시(중간) 등록이라면, 큰 이슈는 없습니다.
  • 임시 등록 예시: VPC 없이 SG 등록 -> 전체 등록 사전 처리 등 -> 등록한 SG 삭제 후 VPC Name과 함께 SG 최종 등록
• VPC Name 없는 SG 등록이 최종 등록 형상이라면,
  • 추상화 개념이 수정되어야 하므로,
  • 반영 전에 아래와 같은 몇 가지 고려 사항들이 있습니다.
  • 고려해보시고 변경에 대한 의견들 남겨 주시기 바랍니다.

[변경 요약]

• AS-IS: VPC->SG 타입만 존재
  • => SG 운영 방식 통일, SG 등록 시 VPC 의존 없어도 VPC Name 설정 필요(SG 자동 등록 불가)
• TO-BE: CSP 지원 방식에 맞게 VPC->SG 타입과 VPC, SG 타입 혼합 운영
  • => SG 자동 등록 가능, CSP별 VPC와 SG 의존 관계 그대로 유지, 추상화 약해짐

[고려 사항]

• 변경 시, TB 등 기존 사용자는 대상 CSP 지원 방식에 따라 VPC->SG, VPC, SG 타입을 인지하고 생성/관리 필요
• SG 타입 분리에 따른 Migration 영향 사전 검토 필요 ------- @yunkon-kim

@powerkimhub

• VPC Name 없는 SG 등록이 최종 등록 형상으로 고려하고 있습니다.

이는 "기존 자원 등록"의 경우, CSP에 따라, 실제로도 SG와 VPC 간 관계가 없고, 관계에 대한 정보도 없기 때문입니다. (그리고 억지로 정보를 찾아서 매핑한다고 해도 활용 측면에선 의미가 없어 보입니다.)

아울러, "기존 자원 등록"의 경우, cloud-barista에서 완벽하게 재 등록하기가 어렵다는 점을 고려해야 할 것 같습니다.
(CSP에는 없는 개념이, CB 추상화 과정을 통해 만들어진 경우. )
따라서 예외 처리하는 방식(추상화 개념 자체를 수정하는 것이 아니라, 예외로 대하는 것)으로 제안을 드렸으며,
CB-TB에서는 이미 이를 정보로 관리하고 있기 때문에 (언급해주신 고려사항) 문제가 없다고 판단하고 있습니다.

이외의 고려 사항은 현재 제안된 PR 내용 이외의 부분에서

• CB-SP에서 SG 정보/리스트 확인이나, VPC 정보/리스트 확인 시, validation 차원에서 상호 관계를 확인하고 없을 때 오류를 리턴하는 부분이 있다면, 문제가 될 수 있을 것 같습니다.
• SG 룰을 업데이트할 때, 드라이버별로 VPC 쪽으로 처리를 해야 하는 경우가 있다면, 이는 확인이 필요해 보입니다. 그러나, 이것도 CSP의 제약에 의해 발생하는 문제이고, "기존 자원 등록" 으로 등록된 자원에 한정이기 때문에 문제가 없어야 정상적일 것 같습니다.

[고려 사항] 관련 응답.
변경 시, TB 등 기존 사용자는 대상 CSP 지원 방식에 따라 VPC->SG, VPC, SG 타입을 인지하고 생성/관리 필요
--> 이렇게 처리하고 있습니다. (특별히 문제 없다고 판단됩니다.)

@powerkimhub (@seokho-son)

마이그레이션 측면의 현황을 공유드립니다.

현재 VM 인프라 마이그레이션은 vNet (VPC) 생성 후, 해당 vNetId를 활용하여 Security Group를 생성하는 순서로 진행합니다.

[고려 사항] 관련 응답.
변경 시, TB 등 기존 사용자는 대상 CSP 지원 방식에 따라 VPC->SG, VPC, SG 타입을 인지하고 생성/관리 필요

위 내용을 Tumblebug의 사용자인 Beetle의 관점에서 바라보면, Security Group를 생성하는 측면에서 보는 게 정확할 것이라 생각되었습니다(생성 측면 O, 등록 측면 X).

(As-Is) 다음 API Request Body의 vNetId가 필수(required) 값이었음
(To-Be) 앞으로는 vNetId가 선택(optional) 값이 됨

• API: POST /ns/{nsId}/resources/securityGroup
• Request Body:

{
  "connectionName": "string",
  "cspResourceId": "required for option=register only. ex: csp-06eb41e14121c550a",
  "description": "string",
  "firewallRules": [
    {
      "CIDR": "0.0.0.0/0",
      "Direction": "inbound",
      "Ports": "22,900-1000,2000-3000",
      "Protocol": "TCP"
    }
  ],
  "name": "string",
  "vNetId": "string"
}

ref) https://cloud-barista.github.io/api/?url=https://raw.githubusercontent.com/cloud-barista/cb-tumblebug/main/src/interface/rest/docs/swagger.yaml#/%5BInfra%20Resource%5D%20Security%20Group%20Management/PostSecurityGroup

VPC->SG, VPC, SG 타입을 인지하고 생성/관리 필요가 아래 2가지 중 어떤 방향이 될지 문의드립니다. Beetle 차원에서 정확하게 이해하기 위해 문의드리는 사항입니다.

1. TB 사용자가 각 CSP별로 vNet - SG 연관 관계 유무를 인지하고 TB API 호출, SP API 호출 직전 연관 관계가 있으면 vNetId 입력, 없으면 생략
2. TB 사용자가 기존 처럼 SG를 생성 시 vNetId 입력하고, SP에서 연관 관계가 있으면 vpcId (vNetId) 입력, 없으면 생략

혹시 잘못 이해한 부분이 있다면 코멘트 부탁드립니다.

@yunkon-kim

Tumblebug의 사용자인 Beetle의 관점에서 바라보면, Security Group를 생성하는 측면에서 보는 게 정확할 것이라 생각되었습니다(생성 측면 O, 등록 측면 X).

• 말씀주신 것과 같이, Beetle은 현재는 생성 측면을 위주로 활용하시면 되므로, 기존과 변경되는 사항이 없습니다.
• 등록 시점에만, vNetId 가 API 상 의무가 아닌 것으로 변경되었다고 이해해 주시면 되겠습니다. (향후, 생성 요청과 등록 요청의 모델을 구분해서, 해당 항목에 대한 required 를 다르게 설정할 예정)

VPC->SG, VPC, SG 타입을 인지하고 생성/관리 필요가 아래 2가지 중 어떤 방향이 될지 문의드립니다. Beetle 차원에서 정확하게 이해하기 위해 문의드리는 사항입니다.

TB 사용자가 각 CSP별로 vNet - SG 연관 관계 유무를 인지하고 TB API 호출, SP API 호출 직전 연관 관계가 있으면 vNetId 입력, 없으면 생략
TB 사용자가 기존 처럼 SG를 생성 시 vNetId 입력하고, SP에서 연관 관계가 있으면 vpcId (vNetId) 입력, 없으면 생략

아래와 같이 생각하시면 되겠습니다.

• 생성 시점(CB-TB를 통한 생성)에는 완전히 기존과 동일하게 처리
• 등록 시점(CB-TB를 통한 외부자원 등록)에는 사용자가 vNetId 입력 여부 판단(CSP에 따라 다름). 단! 사용자가 하나씩 직접 수행하기 보다는, CB-TB 워크플로우를 통해 이부분이 대부분 자동 처리. (vNet 등록 후, SG가 등록되게 됨)

@seokho-son

• 추가 질문 드립니다.
• (1) SG 등록 후에는 SG를 매단 VPC와 SG가 없는 VPC가 섞여 있는 것인지요?
• (2) 아니면, SG 등록 후에는 VPC->SG 형태만 존재하는 것인지요?
• (1)의 경우라면, 결국 사용자가 CSP별로 SG 운영 방식을 알아야 할듯한데요.
  • 예) VPC로부터 SG 정보를 얻을 수 있는 CSP들과, 얻을 수 없는 CSP들 등

@seokho-son

• 추가 질문 드립니다.

• (1) SG 등록 후에는 SG를 매단 VPC와 SG가 없는 VPC가 섞여 있는 것인지요?

• (2) 아니면, SG 등록 후에는 VPC->SG 형태만 존재하는 것인지요?

• (1)의 경우라면, 결국 사용자가 CSP별로 SG 운영 방식을 알아야 할듯한데요.

  • 예) VPC로부터 SG 정보를 얻을 수 있는 CSP들과, 얻을 수 없는 CSP들 등

현재는 1번 방식으로 처리되어 있습니다.

(1) SG 등록 후에는 SG를 매단 VPC와 SG가 없는 VPC가 섞여 있는 것인지요?

(1)의 경우라면, 결국 사용자가 CSP별로 SG 운영 방식을 알아야 할듯한데요.
예) VPC로부터 SG 정보를 얻을 수 있는 CSP들과, 얻을 수 없는 CSP들 등

• 사용자 입장에서는, SG 등록시에 VPC 정보가 꼭 필요한지 여부만 알면 되는 것 같습니다. (또는 시스템 피드백에 의해서, 입력해주면 됩니다.) 보통은 이 행위를 사용자가 별도로 할 일도 없을 것 같긴합니다.
• SG가 등록된 이후에는, 사용자가 해당 SG가 VPC와 연결되어 있는지 아닌지 자체를 확인할 필요가 없을 것으로 판단됩니다. (혹시 이런 필요성이 있다면 알려주시면 감사하겠습니다.)
  • 따라서, 정보상 SG-VPC가 연결이 되어 있는 경우에는, 실제 연결성을 제공하는 CSP이므로, 기존 방식 그대로 처리가 되고,
  • 따라서, 정보상 SG, VPC가 연결이 안되어 있는 경우에는, CSP 상에서도 실제 연결성이 없는 경우라서, 별도로 추가 처리할 것이 없는 상태가 됩니다.
  • 추가적으로 의존성 관계는 CB-TB 에서 별도의 오브젝트로 관리하고 있어서, 1차적인 방어 (삭제 허용 여부 등)을 진행하게 됩니다. 이 경우에도 큰 이슈는 없어보입니다.

[Off-line 회의 결과 요약]

• 현재 PR 반영 후 장기 운영을 통해 필요시 추가 보완
• PR 요약
  • (1) SG 등록 시 VPC Name 입력 Validation Skip
  • (2) VM 생성시 KeyPair 존재 여부 체크 Skip