SSL, 리버스 프록시 적용

 

 

CI/CD도 완성했고  이제 인프라에서 남은건 엔진엑스 리버스 프록시와  SSL인증서를 적용한 https다.

 

 

 

---

 

 

 

Https 인증부터 완성하였다.

Certbot을 이용한 방법을 사용하였고, 3달마다 갱신해야하는 불편함이 있지만

젠킨스 쉘스크립트에서 cd가 될때마다 갱신하도록 넣는 방법도 있고, 

가끔 생각날때마다 해주면 되므로 크게 부담이 되지는 않았다.

 

 

 

나는 도커안에 엔진엑스를 설치했기 때문에 외부에서 인증서만 받은 다음

마운트해주는 방식을 사용하였다

sudo certbot certonly --standalone -d URL 입력


참고로 URL은 도메인형식이어야하며 ec2의 ip주소는 안된다.

입력하면 질문이 세개 나오는데
첫번째는 이메일입력
두번째는 약관동의
세번째는 정보수신제공 동의이다.

첫번째, 두번째는 동의하였고  세번째는 동의하지 않았다.

 

 

 

 

그리고 docker-compose.yaml 과  nginx.conf 파일을 수정해주면 끝난다.

docker-compose.yaml  수정

  nginx:
    image: nginx:latest
    container_name: ㅁㅁ-nginx
    restart: always
    ports:
      - "80:80"
      - "443:443"         		      // ssl 사용을 위해 오픈
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
      - /etc/letsencrypt:/etc/letsencrypt       // ssl 저장 경로  
    networks:
      - 백엔드,프론트엔드, 디비를 연결하는 내부 network

 

 

 

nginx.conf 생성


events {worker_connections 1024;}

http {
    server {
	listen 80;
	server_name 우리도메인;

	location / {
		return 301 https://$host$request_uri;
	}
    }

    server {
	listen 443 ssl;
	server_name 우리도메인;

	ssl_certificate /etc/letsencrypt/live/우리도메인/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/우리도메인/privkey.pem;

	location / {
		proxy_pass http://frontend:80;
		proxy_set_header Host $host;
		proxy_set_header X-real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header X-Forwarded-Proto $scheme;
	}

	location /api {
		proxy_pass http://backend:8080;
		proxy_set_header Host $host;
		proxy_set_header X-real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header X-Forwarded-Proto $scheme;
	}
	
	location /login/oauth2 {
		proxy_pass http://backend:8080;
		proxy_set_header Host $host;
		proxy_set_header X-real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header X-Forwarded-Proto $scheme;
	}

	location /oauth2 {
		proxy_pass http://backend:8080;
		proxy_set_header Host $host;
		proxy_set_header X-real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header X-Forwarded-Proto $scheme;
	}

	location ~ ^/(swagger|webjars|configuration|swagger-resources|v3|csrf) {
		proxy_pass http://backend:8080;
		proxy_set_header Host $host;
		proxy_set_header X-real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header X-Forwarded-Proto $scheme;
	}
	
   }
}






# 프록시 요청의 호스트 헤더를 원래 요청의 호스트 헤더값으로 설정.  백이 요청 올바르게 처리가능
proxy_set_header Host $host;            

# x-real-ip 헤더를 원래 요청의 클라이언트 ip로 설정   백이 실제 클라이언트 IP를 알 수 있음
proxy_set_header X-Real-IP $remote_addr;    

# 이 헤더를 원 클라이언트 IP와 프록시서버의 IP를 포함한 리스트로 설정.  
#  백이 클라이언트의 원래 IP와 요청 경로를 추적하는데 사용
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

# 이건 백이 요청이 https인지 http 인지 알게 해줌
proxy_set_header X-Forwarded-Proto $scheme;

 

 

 

 

 

---

 

 

 

 

트러블 슈팅

프론트는 잘 적용되는데 백엔드 리버스프록시를 거치고 나니 https 적용이 안된다.

프론트엔드와 백엔드 코드 그리고 엔진엑스와의 호환문제였다.

 

프론트엔드와 백엔드 코드를 외부에서 들어오는 연결은 https로

내부에서 연결되는 것들은 http로 연결해서 해결하였다.

 

내부에서 http로 연결하는 이유는  

외부에서 https를 타고 넘어오면 게이트웨이를 넘어온 것과 같으므로 

내부적으로는 https를 써가며 보안을 할 필요가 없다.

그래서 일반적으로 내부 연결은 http를 많이 사용한다.