EKS 에서 http 를 https 로 리다이렉트 시켜주는 ALB 가 필요하다면, 아래와 같은 ingress 를 구성한다.

 - 사전에 ACM 의 인증서 arn 이 필요하다.

$ vi ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: example
  name: example-ingress
  annotations:
    # Ingress Core Settings
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/target-group-attributes: stickiness.enabled=true,stickiness.lb_cookie.duration_seconds=60
    # SSL Settings
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:ap-northeast-2:111122223333:certificate/11fceb32-9cc2-4b45-934f-c8903e4f9e12
    alb.ingress.kubernetes.io/ssl-redirect: '443'
spec:
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: example-nodeport
                port:
                  number: 80

기존 http 구성에 # SSL Setting 아래 3줄만 추가하였음.

기존 ingress 삭제하고 다시 생성.

$ kubectl delete -f ingress.yaml
ingress.networking.k8s.io "example-ingress" deleted

$ kubectl apply -f ingress.yaml
ingress.networking.k8s.io/example-ingress created

매번 인프라가 다 해주다보니 ACM 인증서 발급도 한번 못해봤는데, 공짜인줄은 몰랐네;

https 통신은 ssl 보안 서버 인증서가 필요하다. ssl 인증서는 한국정보인증을 비롯한 많은 곳에서 구매가 가능한데 AWS Certificate Manager(ACM) 에서는 이 비싼(?) ssl 인증서를 무료로 제공한다. ALB, Cloud Front, API Gateway, ... 등에서 이 인증서를 사용할 수 있으며 따로 설치가 필요없다.

예를 들면, Cloud Front 에 S3 와 ssl 인증서를 연결하고 특정 도메인을 Cloud Front 에 연결하는 단계는 다음과 같다.

S3 - 특정 버킷의 특정 디렉토리에 리소스 업로드
ACM - 특정 도메인의 인증서 생성
Cloud Front - 배포 생성하여 S3 와 ACM 연결
Route 53 - 레코드 생성하여 Cloud Front 연결

1. Route 53 DNS 설정

AWS 에서 도메인을 관리하기 위해서는 Rourte 53 에 호스팅 영역을 추가하고, 레코드를 생성한다. 외부 도메인일 경우 도메인 구매한 곳(가비아나 카페24 같은?) 에서 네임서버를 해당 NS 값으로 변경해 준다. 아래와 유사한...

• ns-94.awsdns-12.com.
• ns-1975.awsdns-56.co.uk.
• ns-1181.awsdns-18.org.
• ns-743.awsdns-28.net.

2. ACM 인증서 요청

인증서는 반드시 미국 동부(버지니아 북부) 리전(us-east-1)에서 요청해야 하며, 그렇지 않으면 Cloud Front 에서 해당 인증서를 선택할 수 없다. 인증서 요청시, 사용하려는 여러 도메인을 등록해도 되고 아래처럼 모든 2차 도메인 처리(*)와 2차 도메인이 없는 두가지 경우를 등록해도 된다.

• example.com
• *.example.com

해당 도메인에 대해 DNS 검증을 하며, Route 53 에 해당 레코드가 작성되어 있지 않다면 인증서 요청시 생성된 CNAME 으로 레코드 생성이 가능하다.

약 1분 내로 인증서 상태가 [검증 대기 중] 에서 [발급됨] 으로 변경되며, 이제 *.example.com 도메인에 대해 https 통신을 할 수 있다. 검증이 30분에서 이틀까지 걸렸다는 글들도 있던데 난 모르겠고...

3. Cloud Front 배포 생성

• 원본 도메인(S3) 및 경로 설정
• 대체 도메인 이름(CNAME) 추가: example.com, www.example.com, ...
• SSL 인증서 선택
• 프로토콜 정책: Redirect HTTP to HTTPS (HTTP 시도시 HTTPS 로 연결)
• 기본값 루트 객체: index.html (default 파일)

4. Route 53 도메인 연결 (별칭-alias)

• example.com (A) www.example.com.
• www.example.com (A) d1asdfqwerasdf.cloudfront.net.

여기까지 설정했다면 example.com 도메인으로 접속했을 때 https://example.com 으로 연결되며 cloudfront 를 통해 s3 리소스를 확인할 수 있어야 한다. (Response Header 에서 cloudfront 확인) 

403 forbidden error 등이 발생한다면, S3 버킷 정책을 public access 가 가능하도록 설정한다.

간만에 톰캣 단독 서버를 만들면서 포트 포워딩에 대한 노가다를 해보았다.

톰캣은 기본적으로 8080 포트와 8443(SSL) 포트를 사용하기 때문에 대부분의 경우 80 포트나 443 포트로 변경하기를 원할 것이다.

도커 등의 각종 컨테이너 서비스를 사용하면 포트 걱정할 일은 없지만, 포트 포워딩이 아닌 포트 변경이 가능한 방법을 찾아봤다.

> server.xml 

톰캣이 실행중일 때 netstat 로 listen 중인 포트를 확인해 보면 8080, 8443 포트가 열려 있는 것을 확인할 수 있다.

server.xml 파일에 설정되어 있는 포트 때문인데, 이 포트들을 원하는 포트로 변경한다고 해서 모두 동작하지는 않는다.

1024 이하의 TCP/UDP 포트(well-known) 로 변경하려 할 경우 root 권한을 필요로 하기 때문에 기본 세팅으로는 well-known 포트로 변경 할 수 없다.

(이를 가능하게 하는 것이 authbind 이다.)

이러한 이유로 우리는 tomcat 유저로 톰캣을 실행시킬 경우 포트를 80 이나 443 등으로 바꾸려는 무모한 짓으로 시간을 낭비하지 말아야 한다.

이를 확인하려면 tomcat8.conf 파일의 TOMCAT_USER 를 root 로 설정하면 server.xml 에 설정한 대로 포트가 변경되는 것을 확인할 수 있다.

하지만 운용시 생성되는 모든 파일, 배포 디렉토리 및 log 파일까지 모두 root 로 설정되기 때문에 일반 유저로는 접근할 수 없어 좋은 방법이 될 수 없다.

그 어떤 서비스도 해당 그룹과 권한을 설정하여 사용하지, root 로 실행하라고 권하는 서비스는 없다.

결국 깔끔한 방법은 포트 포워딩이다.

80->8080, 443->8443 포트 포워딩

이렇게 iptables 로 포트 포워딩을 하면 80 과 443 을 사용할 수 있다.

iptables 대신 firewalld 를 사용할 수도 있다.

80->443 포트 포워딩

이 상태에서 80 포트으로 접속했을 때 무조건 443 포트로 포워딩하려면 web.xml 파일을 수정한다.

여기서 server.xml 파일의 redirectPort 를 443 으로 바꿔주면,

firewalld 를 사용할 때는 http 접속시 https 로 자동변경 되지 않아 server.xml 파일에 추가 설정이 필요했다.

8443 포트 막기

마지막으로 https://mydomain.com:8443 같은 식의 8443 포트로 직접 접근을 막기 위해 iptables 를 한번 더 수정한다.

일반적으로 http 통신을 이용하는 도메인은, http://www.example.com 과 같은 형식으로 나타낼 수 있다. 

설정에 따라 example.com 으로만 접속해도 같은 결과를 볼 수도 있다.

하지만 SSL/TLS 보안서버를 구축하고 나면 https 통신을 해야 하고, http 요청 또한 https 로 전환을 해주어야 한다.

https://www.example.com 만을 필요로 하는 나를 힘들게 한건 바로 https://example.com 과 같은 식의 URL 요청이다.

대부분 *.example.com 같은 도메인으로 인증서를 발급하기 때문에, 2차 도메인을 제외한 example.com 을 별도로 구매하지 않았다면

https://example.com 식의 URL 로 접근할 경우, 보안 인증서에 문제가 있다는 브라우저 경고를 만나뵐 수 있다.

서버로의 진입점에서 바로 경고가 발생한 것이므로, 소스에서 자바스크립트나 meta 태그, 각종 프레임워크 등을 이용한 리다이렉션 하는 등의 뻘짓은 무의미하다.

내가 한 회심의 뻘짓은 바로 rewrite 를 이용한 것이었다. 안될 줄 알았지만 혹시나 한번 해봤다ㅋ

Apache 에서는 많이 사용해 봤지만 Tomcat 에서는 처음이라 기록해 본다.

우선 server.xml 의 <host> 나 context.xml 파일에 아래 지시자를 넣는다.

그리고 어플리케이션의 /WEB-INF 디렉토리 안에 rewrite.config 파일을 넣고 rewrite 명령어들을 이용해서 리다이렉션을 구성한다.

짠~

이것은 요청 URL 이 example.~~~ 로 시작한다면 앞에 https://www. 을 URL 앞에 붙여 리다이렉트 시키는 명령문이다.

따라할 필요는 없다. 어짜피 경고는 그대로 나타나니까. 더 앞 단에 뭔가를 해줘야 하는데 난 모르겠다.

위의 오류를 발생시키지 않기 위한 방법?? 그냥 깔끔하게 돈 더 내고 인증서에 도메인 하나 더 추가하는 것이다ㅋ

IE 나 파폭에서 https://naver.com 을 들어가보라

네이버도 경고 뜬다...ㅋㅋ

https://www.oops4u.com/main 접속

# 사이트에 보안 연결할 수 없음

# https://www.oops4u.com 에서 지원되지 않는 프로토콜을 사용합니다.

# ERR_SSL_OBSOLETE_CIPHER

ERR_SSL_OBSOLETE_CIPHER... SSL 구식암호라... 

어제 크롬을 최신버전으로 업데이트 하고나서 발생한 오류.

지원되지 않는 프로토콜을 사용합니다... 라니...

단순히 https 일 뿐이고, IE / FF / 구크롬에서는 잘 되는 페이지인데 최신크롬에서만 안된다니!

server.xml 의 Connector 설정에는 TLS 프로토콜을 사용하도록 설정되어 있다.

현재 크롬 버전 : 53.0.2785.116 m

ERR_SSL_OBSOLETE_CIPHER 에 대해서 검색을 해봤다.

딱히 도움되는 내용은 없다 ㅡㅡㅋ 

cipher 로 검색했더니 톰캣에서는 ciphers 리스트 기본값에 보안이 취약한 cipher 가 포함되어 있어서 직접 설정하는 것을 권장(?)했다.

https://www.openssl.org/docs/manmaster/apps/ciphers.html 에서 필요한 프로토콜의 suite 를 긁으면 된다.

server.xml 파일에 아래처럼 cipher 값들을 넣어줬더니 해결되었다.

L4, ELB 에 붙은 실서버들은 멀쩡한데, 왜 똑같은 Tomcat8 설정에 유독 이 개발서버 한대만 이런일이 발생했는지 모르겠지만

어쨌든 크롬에서는 이번 업데이트에 https 보안에 대해 조금더 신경을 쓴 것 뿐이고,

나처럼 cipher 설정이란 것을 모르고 있는 기업들에서는 열라 땀 삐질한 것 뿐이고,

크롬 오랫동안 참 좋게 봤는데, 이런 건방진 수준의 업데이트 할 줄이야...