티스토리 뷰
VPC내에 ES를 사용하고 있다. VPC내 ES로 접근하기 위해서는 ssh tunneling을 사용하거나 proxy 서버를 구성하여 접근 해야한다.
ES를 보고서를 작성할 때만 사용하고 있어서 많은 설정이 필요 없는 ssh tunneling으로 사용하고 있었다. 하지만 점점 사용 빈도가 늘어나면서 매번 tunneling을 하는 것이 귀찮아졌다. kibana에 개발자가 아닌 사람이 접속할 상황이 생기고 점점 tunneling을 관리하기가 어려워졌다.
Amazon Cognito 인증으로 Kibana에 액세스하기 위해 SSH 터널 사용
위의 그림 처럼 tunneling을 사지 않고 proxy 서버를 통해 traffic이 VPC 내부에 있는 ES로 접근할 수 있도록 구성했다. ES에 접근 시 cognito의 login을 하여 인증된 사용자에게만 권한을 부여하고 ES를 사용할 수 있도록 구성했다.
Nginx Proxy Server 설정
기존에 ssh tunneling으로 사용하는 EC2 instance는 spot instance였다. Spot instance는 싸지만 언제든지 새로운 instance로 교체될 수 있다. 지속적으로 사용해야하는 경우 on-demand 또는 reserved instance를 생성해야한다.
Let’s encrypt
ALB를 사용하면 ACM 서비스를 이용하여 SSL 인증서를 관리할 수 있고 확장성이 용이한 구성을 할 수 있다. 하지만 ALB사용 시 유지비용이 추가된다. 회사 내부에서만 ES에 접근하는 상황이라 EC2 instance 하나만 사용했다.
ALB나 Cloudfront를 사용하지 않고 EC2 instance 만 사용하는 경우 ACM을 사용할 수 없다. SSL 인증서를 발급받기 위해 let’s encrypt를 사용했다. Amazon Linux2를 사용하는 경우 Let’s encrypt를 사용하는 방법은 아래 링크에 자세하게 설명되어 있다.
자습서: Amazon Linux 2에서 SSL/TLS 구성 - Amazon Elastic Compute Cloud
Certbot으로 인증서를 발급받을 때 주의할 사항은 먼저 route53에 EC2의 public ip에 특정 도메인을 먼저 연결하고 EC2 instance의 Security Group 80 port를 열어야한다.
nginx proxy 설정
resolver 10.0.0.2 ipv6=off;
# 80 -> 443
server {
listen 80;
server_name $host;
set $es_endpoint <ES_ENDPOINT>;
return 301 https://<ES_ENDPOINT>;
}
server {
listen 443 ssl;
server_name $host;
rewrite ^/$ https://$host/_plugin/kibana redirect;
ssl_certificate /etc/nginx/cert.crt;
ssl_certificate_key /etc/nginx/cert.key;
ssl on;
ssl_session_cache builtin:1000 shared:SSL:10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
ssl_prefer_server_ciphers on;
set $es_endpoint <ES_ENDPOINT>;
set $cognito_endpoint <COGNITO_ENDPOINT>;
location ^~ /_plugin/kibana {
# Forward requests to Kibana
proxy_pass https://$es_endpoint;
# Handle redirects to Amazon Cognito
proxy_redirect https://$cognito_endpoint https://$host;
# Update cookie domain and path
proxy_cookie_domain $es_endpoint $host;
# Response buffer settings
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
}
location ~ \/(log|sign|error|fav|forgot|change|confirm) {
# Forward requests to Cognito
proxy_pass https://$cognito_endpoint;
# Handle redirects to Kibana
proxy_redirect https://$es_endpoint https://$host;
# Handle redirects to Amazon Cognito
proxy_redirect https://$cognito_endpoint https://$host;
# Update cookie domain
proxy_cookie_domain $cognito_endpoint $host;
}
}
위의 내용을 /etc/nginx/conf.d/default.conf
에 작성하여 nginx server를 재실행한다.
Amazon Cognito 인증으로 Kibana에 액세스하기 위해 NGINX 사용
ElasticSearch Service 설정
ElasticSearch Service에 cognito 인증을 설정하기 위해서 인증 수정
버튼을 클릭한다.
인증 수정에서 사용할 user pool과 identity pool을 설정한다. console에서 설정하면 자동으로 앱클라이언트 설정과 앱클라이언트와 연결된 identity pool을 설정해준다.(자동으로 앱클라이언트가 생성된다.)
ES와 cognito를 연결했다면 권한을 설정해야한다. (위의 과정만 진행하면 kibana endpoint로 접근 시 로그인 페이지가 나오지 않고 바로 kibana로 접속된다.)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<account id>:role/<인증된 사용자 역할>"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:<region>:<account id>:domain/<es domain name>/*"
}
]
}
identity pool의 설정에서 인증된 사용자 역할을 위의 json에 채운다.
'develop' 카테고리의 다른 글
AWS KMS (0) | 2021.10.17 |
---|---|
node.js multi processing, threading (0) | 2021.04.02 |
Airflow 기본 시용법 정리 (0) | 2021.01.22 |
S3 tagging으로 lifecycle 적용하기 (0) | 2020.11.11 |
VPC 내부 Neptune DB 클러스터 접근을 위한 리버스 프록시 서버 구성 (0) | 2020.09.18 |
- Total
- Today
- Yesterday
- Terraform
- Airflow
- Github Actions
- conventional commit
- NLP
- aws
- Clickjacking
- Lifecycle
- Python
- nginx
- Neptune
- shorten
- AWS community day seoul
- Prisma
- Develop
- inversify
- mongoDB
- nltk
- commit message
- JavaScript
- graphql
- lambda@edge
- typescript
- pagination
- mognodb
- Elasticsearch
- slowquery
- Cognito
- sementic version
- Cloudfront
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |