왜 필요할까?
Azure에서 network를 구성하려고 한사람들이라면, private endpoint와 service endpoint라는 단어에 대해서 들어본적이 있을 것이다.
하지만, 처음 해당 단어들을 볼 때의 느낌은, Azure Virtual Machine 처럼 이름을 통해 어떤 서비스인지 바로 알기는 힘들다.
얘네 왜 필요할까?
특정 PaaS 서비스들은 기본적으로 public으로 나온다.
보안 요건 및 설계상, 내부로 통신해야 할 때, 해당 PaaS 서비스의 public 접근을 닫고, private하게 접근 가능하게 쓰고 싶을 때 사용할 수 있다.
예를 들어보자
- Azure 위에 서비스를 구축했다.
- 이 서비스에 필요한 데이터를 Storage account에 넣고 쓴다.
- Storage account에 있는 데이터는, 중요 데이터이기에 public 접근을 막고, 구축한 vnet에서만 접근 가능해야한다.
- 2가지 선택지가 있다.
- service endpoint를 사용하여 특정 subsnet에서의 접근만 허용
- private endpoint를 사용하여 vnet 안에 nic를 통해 private ip를 부여하여, private ip를 통해서만 접근 허용
service endpoint나 private endpoint를 쓴다고, public 접근 제어가 자동으로 되는 것은 아니지만, public을 접근을 막는 옵션은 대부분 제공하고 있다.
두가지 어떻게 다를까?
private endpoint와 service endpoint의 가장 큰 차이점은, private ip 유무다.
private endpoint는 private ip가 주어지기에, 해당 private ip를 통해 접근이된다.
하지만, service endpoint는 특정 서브넷 또는, 특정 ip에서만 접근 가능하게, 약간 nsg를 열어주는 느낌(?)으로 접근할 수 있게 해준다.
service endpoint는 아래와 같은 화면을 통해 접근을 허용해주며,
private endpoint는 아래와 같이 private ip를 가지고 있는 nic가 private endpont와 함께 생성된다.
service endpoint는 Azure 내부에서 설정을 통해 허용한다고하지만, private endpoint는 어떻게 사용이 되는걸까?
private endpoint의 behind story
service endpoint는 이해 했는데, private endpont는 실제 써보니, public 열어 놓은 상태에서 적용했더니 되게 신기하던데?
밖에서 접근할 때는 public으로 접근하고, vnet 안에서 접근해보니 vnet 안쪽 트래픽 타고가던데? 어떻게 이렇게 되지???
이게... 대기업의 cloud?
우선 private endpoint가 생성되지 않아을 때를 살펴보자.
먼저 아래의 Storage account endpoint의 레코드를 따라가면 아래와 같다.
stvelog 라는 이름을 가진 Storage account는, blob.se1prdstr03a.store.core.windows.net 라는 cname으로 이어져있고, blob.se1prdstr03a.store.core.windows.net의 a 레코드인 52.239.148.4가 우리가 찾는 ip주소가 나온다.
private endpoint를 생성하면 어떻게 될까?
아까와는 다르게 privatelink라는 이름이 들어간 cname이 하나 더 들어가있는 것을 볼 수 있다.
private endpoint를 만들때 기억을 잘 돌려보면 아마 아래와 같이, private dns를 만들었을 것이다.
Azure vnet 안에서 dns 질의 할 때, private dns 부터 질의를 하니, 위와 같이 private dns를 vnet에 적용해 놓으면, 아래와 같은 순서로 서비스를 찾아갈 것이다.
- 외부로 endpoint를 질의
- 위쪽과 같이, privatelink가 붙은 cname으로 받음
- privatelink가 붙은걸 다시 질의하는데, private dns가 해당 값을 들고 있으니, 10.1.0.4 a 레코드인걸 받음
- 10.1.0.4로 접근
기존의 서비스에 굉장히 스마트하게 내부 통신을 붙여놓아서, 처음에 확인하였을 때 상당히 놀랬다.
기존에 설정해놓은 public 접근도 그대로 public으로 붙고, 내부로 붙을 때는 네트워크가 연결되어져 있으며 dns 서버 및 private dns에도 설정을 해놓았다면, 내부로도 아주 유연하게 붙을수 있어 보인다.
그리고 외부 dns 질의만 막아놓지 않았다면, 내부 dns 서버에다가 서미스명.privatelink.blob windows.net 레코드에 private ip만 적어놓으면 된다.
외부 질의를 막았다면, 안에서 바로 원래 endpoint에 private ip 적어놓고 쓰면된다.
마치며
외부를 닫고 내부에서만 접근 가능하게 쓰고 싶다라고 한다면, service endpoint나 private endpoint로 돌파구를 찾아보면 어떨까 한다.
사실 public을 막으면, 완전 검색조차되지 않는게 아니라 access deny 느낌이긴한데, 이제 onprem에서 했던 것과 같이 "무조건 네트워크적으로 다 차단되어있어야 한다"라는 느낌은 너무 old한 요건인것 같다.
이제 보안 요건들도 좀 cloud에 맞춰서 발전 좀 하자 ㅠㅠ
물론 특정 서비스들은, dedicated 라는 단어를 써서 진짜 밖에서 내 vnet 안에다 내려주는 서비스들도 간혹있다.
