# \[GCP] GCP의 ALB ## GCP의 ALB ### AWS ALB와 차이점 * GCP는 고정 IP 할당이 가능하다. - GCP Win * ALB는 고정 IP가 없는대신 전용 endpoint가 있음 * GCP는 프론트앤드 백엔드 라우팅 룰 / AWS 는 리스너 타겟그룹 * GCP는 VM(EC2)로 ALB와 연결 할 시 무조건 instance group을 생성 해야 함 * Proxy 구성 차이(AWS Win) * GCP는 http -> https redirect 구성을 만드려면 alb가 두개가 생성 되야함\ 심지어 새로 생성되는 alb이름도 못지어줌j * 그에 비해 aws는 상당히 높은 수준의 프록시 설정이 가능함 깊게는 http 헤더 대다수에 조건을 걸 수 있음 ### 연결가능한 백앤드 서비스 * ALB는 아래 그림의 서비스들과 연동이 가능하다 ![alt text](https://2888202773-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdMp3YANqsngVZaxVVK0e%2Fuploads%2Fgit-blob-e2ee09da0f85b4d4ca387e5cbf402b17daf13ed4%2Fimage-2.png?alt=media) *** #### 테스트 환경 구성 요소 ![alt text](https://2888202773-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdMp3YANqsngVZaxVVK0e%2Fuploads%2Fgit-blob-957d3b99a6b1fe5c9ac1207865e489f85d0c7d27%2Fimage-1.png?alt=media) * 개요 * http로 접근 시 https로 redirect * 접근 시 vm의 8850 포트로 접근 * 필요 resource * firewall * loadbalancer * instance group * cloud domains * cloud dns * A record 셋팅 * certificate manager * 인증서 생성 시 도메인 소유자 신원 확인을 위해 CNAME 인증을 진행 하였으나 이 방식은 alb에서 인식 불가 * 여유가 된다면 AWS 방식으로도 만들어 보겠음 * alb에서 인증서를 생성하는 방식으로 채택 -> 기존 인증서 탭에 인증서 확인 ![alt text](https://2888202773-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdMp3YANqsngVZaxVVK0e%2Fuploads%2Fgit-blob-cedb72dcf2b6a3f5d8b038864d647cb990c9a5b4%2Fimage-3.png?alt=media) * 방화벽 * 80 , 443 , 8850(unkown 포트이기 때문에 방화벽을 추가 별도 구성 해야 함) * alb 과정에서 http , https 를 체크하면 tag가 자동으로 적용 되면서 방화벽 셋팅이 진행 * alb * backend * frontend * https용 frontend alb는 ssl 사용 여부 체크시 자동으로 생성 된다 * routing rule(url map) ```yaml defaultService: projects/storied-imprint-xxx/global/backendServices/backend-kth-pri-bastion-80 name: path-matcher-1 pathRules: - paths: - / - /* service: projects/storied-imprint-xxx/global/backendServices/backend-kth-pri-bastion-8850 ``` * proxy * 직접 만드는 것은 아니지만 alb를 만들면 구성에 맞게 아래처럼 proxy , 전달 규칙 등이 생성 된다. ![alt text](https://2888202773-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdMp3YANqsngVZaxVVK0e%2Fuploads%2Fgit-blob-7d6395a4c078d3c348ea58f4e59ea2fbee8c361d%2Fimage-4.png?alt=media) ### 서비스 * instance group * type : * 이 부분이 상당히 중요 한 내용인데 이건 AWS의 AutoScaleGroup의 개념이 있어야 한다.\ 별도 설명 필요, 일단 초보자는 unmanaged instance 선택하면 됨 * managed instance group * stateless * stateful * managed를 고르는 순간 부터 서버에서 변경 사항이 발생 되도 일정 시점 이후 원복이 됨 * 변경 사항은 템플릿으로 관리 하기 때문 * 마치 쿠버네티스의 코드 관리 방식처럼 동작함 * unmanaged instance group * template * image * health check * port mapping * 80:80 * 81:81 * 8850 * VM * NGINX * port 3000 * port 8850 ### web loadbalancer 생성 * name: dorian-p-alb-web-an3 * type: Application loadbalancer * public * region : asia-northeast-3 * frontend * port : 80,8850,81 * ssl redirect check : 자동으로 https 처리용 lb가 생성 * backend * CDN 미사용 * 인증서 생성 * Instance Group mapping * Routing 설정 ### cloud dns * zone : ${domain zone} * a record mapping * dorian:${alb IP} ## 방화벽과 Cloud Armor * 방화벽은 GCP 프로젝트 단위로 광범위 하게 적용 되며 cloud Armor는 global backend 서비스 앞단에 위치함 * cloud Armor의 레이어는 OSI 7 Layer 기준으로 3\~7 이기 때문에 WAF(웹방화벽)과 IPS의 역활을 수행 할 수 있음 * external-global-alb 타입으로 생성 시 방화벽에 health-check를 위해 35.191.0.0/16을 넣어 줘야 하는데 이렇게 되면 특정 IP만 허용 하는 allow 정책이 불가능하게 됨 * 그렇기 때문에 특정 IP의 allow나 deny 정책을 갖고 싶다면 cloud Armor에서 controll 해야 함 아래 그림의 firewall 위치와 cloud armor 위치를 유심 하게 봐야함 ![alt text](https://2888202773-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdMp3YANqsngVZaxVVK0e%2Fuploads%2Fgit-blob-309e1d3c960418d0a498c1d0700e2ddc49a90577%2Fgcp_alb_architecture.png?alt=media) ### firewall * name: dorian-p-sec-in-web-alb-an3 * soruce : 35.191.0.0/16 ${office ip} * target : 172.18.1.0 * protocol : 80,81, 8850 * 주의사항 : 35.191.0.0/16 (gcp global lb 대역)을 추가 해야 heath-check가 진행 됨 ### Cloud Armor * name : security-policy-for-backend-service-dorian-p-alb-backend-web * allow : ${office ip} * deny : 모든 IP 주소