AWS ALB로 접근 제어

접근 제어는 여러가지 방법이 있음

Security Group을 통한 IP

ALB Listener Rule에서 CIDR 기반 필터

WAF를 ALB에 연결

Ingress Controller Annotation을 통한 IP

 

---

 

 

여기선 ALB - ingress를 이용한 접근 제어를 해보려고 함

 

왜?

Security Group은 AWS resource라서 생성해야함

-> 생성하면 삭제도 해야하고 관리해야함

-> 나의 경우엔 영구적으로 필요한 것은 아니기 때문에 굳이?라는 생각

Listener Rule

-> 같은 AWS 리소스

WAF

-> 같은 리소스

 

리소스는 Terraform으로 생성하는 것이 규칙이기 때문에 진짜 임시로 하기 위해서 만든다는 것이 정말 비효율적이라고 생각했던 찰나에 ingress 등장

사실 이 역시 ALB에 적용할 수 있는 리소스지만

Terraform이 아닌 Ingress로 history를 남길 수 있는 기능

사실 얘도 ALB에 리소스를 만듦(SG와 같음) -> 하지만 ALB controller -> ingress를 계속 watching 하기 때문에 생기는 것으로

ingress에 따라 바뀐다는 동적인 프로비저닝이라고 할 수 있음

Terraform도 물론 동적으로 할 수 있지만 느낌이 다름

Terraform 자체는 정적인 것이고 동적으로 구성을 내가 해줘야함

Controller 자체는 동적이고 태어나길 그렇게 태어남

 

아무튼 ALB를 Ingress로 쓴다면 빠르게 작동할 수 있는 annotation이 있다.

https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/ingress/annotations/

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    alb.ingress.kubernetes.io/inbound-cidrs: "203.0.113.0/24,198.51.100.0/24"

 

요약

AWS 리소스를 직접 만들지 말고SG도 직접 만들지 말고ingress만 간단히 설정하여 inbound-cidr로 whitelist 관리가 가능함

 

 

---

 

밑에는 궁금한 사람만

 

내부 로직

소스코드를 보자

https://github.com/kubernetes-sigs/aws-load-balancer-controller

"sigs.k8s.io/aws-load-balancer-controller/controllers/ingress"

여기에 ingress controller가 있을 것

main은 그냥 루프일 뿐

 

https://github.com/kubernetes-sigs/aws-load-balancer-controller/blob/main/controllers/ingress/

여기선 Ingress Controller를 관리할 것이고

Controller가 하는 동작들이 있을 것이다.

    "sigs.k8s.io/aws-load-balancer-controller/pkg/annotations"

...
    
    annotationParser := annotations.NewSuffixAnnotationParser(annotations.AnnotationPrefixIngress)

	classAnnotationMatcher := ingress.NewDefaultClassAnnotationMatcher(controllerConfig.IngressConfig.IngressClass)
    
    ...

 

역시나 Parser가 있다.

https://github.com/kubernetes-sigs/aws-load-balancer-controller/blob/main/pkg/annotations/parser.go

	AnnotationPrefixIngress = "alb.ingress.kubernetes.io"

여기를 보면 어떤 annoation 을 파싱할 지 감이 온다.

파싱한 후에 값에 따라 행동하는 부분은 어딜까?

inbound-cidr에 대한 annotation이면 해당 feature가 나온 PR을 보면 원래 제일 좋다

https://github.com/kubernetes-sigs/aws-load-balancer-controller/pull/295/files

sg에 annotation에서 파싱된 inbound-cidr를 계속 watching 하면서 reconcile하는 과정이다.

뭐 전체적인 Controller의 흐름은 모르더라도

항상 루프를 돌면서 Watch - Reconcile의 반복이라는 것만 알면 된다.

 

 

요약

Ingress Controller가 변화를 감지하고

특히 inbound-cidr이 파싱 후 바뀌었다면 Reconcile해서 SG에 추가/제거를 함으로써 inbound-cidr이 작동하게 함