AWS와 같은 클라우드 서비스를 웹 콘솔만 이용하여 사용하다보면 각 리소스의 상세 설정이 어떻게 되어있는지, 리소스들간의 관계는 어떻게 되어있는지 한눈에 파악하기가 어렵다. 특히 해당 리소스에 대해 권한을 갖고있는 여러명이 공동 작업을 하는 경우 내가 아닌 다른 사람이 어떤 설정 변경을 했는지 히스토리를 추적하는것이 불가능하다. 이때 테라폼(Terraform)이나 풀루미(Pulumi) 등의 IaC(IaC, Infrastructure as Code) 플랫폼들을 이용해서 리소스를 코드로 표현하여 관리하면 이러한 문제를 해결하는 것이 가능하다. 클라우드 리소스를 코드 형태로 관리할 수 있게 되면 다음과 같은 이점들이 생긴다. ...
mongodb+srv://mongodb-atlas-serverles.asdf.mongodb.net 위와같은 mongodb connection string이 있을때 해당 mongodb에 접속할 수 있는 실제 서버의 IP주소를 알고싶은 경우 다음과 같이하면 된다. # -type=SRV 옵션을 사용해서 DNS 레코드 중 SRV 타입을 검색한다 # connection string에 명시된 주소 앞쪽에 _mongodb._tcp 를 붙여준다. $ nslookup -type=SRV _mongodb._tcp.mongodb-atlas-serverles.asdf.mongodb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: _mongodb._tcp.mongodb-atlas-serverles.asdf.mongodb.net service = 0 0 27017 mongodb-atlas-serverless-example-dev-lb.asdf.mongodb.net. 출력된 결과를 보면 mongodb-atlas-serverless-example-dev-lb.asdf.mongodb.net 부분이있는데 이것이 실제 주소이다. # 위에서 얻은 주소로 다시한번 쿼리 $ nslookup mongodb-atlas-serverless-example-dev-lb.asdf.mongodb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: mongodb-atlas-serverless-example-dev-lb.dvfze.mongodb.net canonical name = 123456-nlb-12345.elb.ap-southeast-1.amazonaws.com. Name: 123456-nlb-12345.elb.ap-southeast-1.amazonaws.com Address: 13.213.131.24 Name: 123456-nlb-12345.elb.ap-southeast-1.amazonaws.com Address: 13.213.229.91 여기서 나온 IP 주소들이 실제 mongodb 서버의 주소이다. ...
PAKE (password authenticated key exchange) PAKE는 두명 이상의 참여자가 패스워드 기반으로 암호화된 채널을 만들어서 서로 통신할 수 있게 해주는 암호학 적인 방법을 말한다. Balanced PAKE 참여자들이 서로 암호화된 채널을 만드는 과정을 위해 동일한 패스워드를 사용하는 방법 Augmented PAKE server/client 시나리오에서 많이 사용된다. 서버는 어떤 password-equivalent 데이터도 저장하지 않는다. (서버는 password로 부터 계산된 값을 보관하고 있지만 이 값으로는 원래 password를 역추론할 수 없다. 이 외에도 password를 역추론 해 낼 수 있는 관련 정보는 저장하지 않는다.) 클라이언트가 서버에 인증을 시도할 때도 password를 역추론 해 낼 수 있는 직접적인 정보는 클라이언트에서 서버로 절대로 전송되지 않는다. 때문에 공격자가 서버의 데이터를 접근 권한을 탈취했다고 하더라도 해당 데이터로 부터 password를 brute force로 찾아내기 전에는 client를 impersonate 하는 것이 불가능하다. SRP (Secure Remote Password) Protocol SRP 프로토콜은 기존 특허를 피해서 만들어진 augmented PAKE의 한 종류이다. 인증 과정에서 password를 유추할 수 있는 직접적인 정보가 원격지로 전달되지 않아서 안전하다는 뜻으로 이름을 이해하면 될 것 같다. (이 이름이 지어진 정확한 기원은 찾지 못했다) SRP protocol은 여러번 수정되어왔고 현재는 revision 6a 버전이다. ...
쿠키(cookie)를 이용한 세션기반의 인증의 경우 특정 웹서버에서 세션 상태(session state)를 유지해야 하기 때문에 stateless 하지않다. 서버 로직이 Stateless가 아닌 경우 더 많은 요청을 처리하기 위해 동일한 서버의 숫자를 늘리는 스케일 아웃(scale out)에 적합하지 않다. 또한 도메인이 다른 서버에 대해서는 해당 세션 쿠키가 공유되지 않기 때문에 도메인이 다른 서버에 요청하기 위해서는 매번 새롭게 인증을 해야하는 불편함도 존재한다. 이 문제를 해결하기 위해 매번 http 요청마다 http header에 인증 토큰(authorization token)을 같이 보내는 형태의 방법을 많이 사용한다. 일반적으로 토큰 안에는 어떤 유저가 보내는 요청인지 구분하기 위해서 유저 ID값이 포함된다. 이 방법을 사용하면 서버쪽에서 세션 상태를 유지할 필요가 없어서 스케일 아웃에 적합하며, 도메인이 다른 서버에 요청하는 경우에도 동일한 토큰을 그대로 사용할 수 있다. 이러한 토큰기반의 인증을 적용하는 경우 악의적인 유저가 다른 유저ID를 사칭하는 것을 방지하기 위해서 토큰에 서명(signature)을 포함하거나, 대칭키 암호화를 적용한다. ...
카프카 Consumer를 사용하다 보면 offset을 reset해야하는 경우가 종종 있다. 개발 테스트를 진행하다가 필요에의해 offset을 리셋 실제 production에서 사용중에 예상치 못한 에러 등으로 데이터 누락이 발생하여 일정기간 전으로 다시 offset을 rewind해서 사용하고자 하는 경우 이런 경우에 Consumer API를 사용중이라면 직접 코드 레벨에서 programmatic하게 reset도 가능하고, 아니면 kafka에서 제공하는 reset tool을 이용해서 reset이 가능하다. 카프카 바이너리 설치 카프카 바이너리를 설치한다. Mac에서 brew가 있다면 아래 명령어로 간단히 설치 할 수 있다. (Mac을 기준으로 설명 한다.) ...