LoginSignup
0
1

More than 3 years have passed since last update.

GKEで運用しているサービスをhttps通信にする

Posted at

はじめに

GKEで個人で運用しているサイトがhttp通信なので、httpsにする

そもそもhttps通信とは

HTTPS (Hypertext Transfer Protocol Secure) は、HTTPによる通信をより安全に(セキュアに)行うためのプロトコルおよびURIスキームである。厳密に言えば、HTTPS自体はプロトコルではなく、SSL/TLSプロトコルによって提供されるセキュアな接続の上でHTTP通信を行うことをHTTPSと呼んでいる。
(wikipediaより)

仕組みのおさらいはこちらから↓(とてもわかりやすい!)
https://employment.en-japan.com/engineerhub/entry/2018/02/14/110000

なぜやるのか

常識的なことだが、https通信にすることで下記のメリットがある。

  • セキュリティ強化
  • SEO
  • 信頼性 などなど

自身で運用しているサイトは、非ログインではあるがユーザーのコメント機能をメインとしているのにもかかわらず、ブラウザのバーに「安全ではありません」と出てしまうのがコメント率を下げていると仮定し、対応する決意に至った

スクリーンショット 2020-07-19 14.30.46.png

GKEで実現するためにやるべきこと

ロードバランサにSSL証明書と証明書の対応する秘密鍵を用意する
証明書は独自で用意する証明書と、Googleが管理する証明書があるが、今回はGoogleが管理する証明書を設定する

ステップ1:ドメインが登録されていることを確認

Google Domainsから自分のサイトの登録状況を確認する
https://domains.google.com/m/registrar/search?searchTerm=http:%2F%2Fsports-memory.com%2F&hl=ja&_ga=2.200045991.867508022.1595137455-1227190297.1595137455#

ステップ2:証明書を作成する

負荷分散ページから設定する
https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs?hl=ja#certificate-resource-status

この時点で作成した証明書のステータスは「PROVISIONING」

ステップ3:ロードバランサの更新

すでにロードバランサを作成済みであったが、TLSで作成していたので、別途、別のロードバランサを作成する

そして、すでに使っている静的アドレスも新しいロードバランサには使えないので、新規でIPアドレスも作成する
その新ロードバランサが作成完了したら、Cloud DNSも変更する方針に切り替える

ステップ4:気を取り直して、新しい静的アドレスを作成

こちらから作成する

ステップ5:ロードバランサも新規作成

プロトコルにHTTPSを選択して、証明書は先程作成した証明書を選択して作成する

スクリーンショット 2020-07-25 15.13.21.png

この状態ではまだ指定のIPアドレスがドメインと紐づかないので、証明書のステータスがPROVISIONINGのままとなる

スクリーンショット 2020-07-25 15.19.59.png

ステップ6:Cloud DNSを変更

ものすごい強引ではあるが、Aレコードを新規で作成したIPアドレスに変更する
Aレコードに追加することで、証明書のステータスがactiveに変わることを確認

ステップ7:GKEで使用しているServiceに紐付け

作成したロードバランサをServiceに紐付けるため、ロードバランサのIPを指定してデプロイするが、下記のようなエラーが出て、紐付けられない、、、

Error creating load balancer (will retry): failed to ensure load balancer for service default/default: requested ip "xx.xxx.xxx.xxx" is neither static nor assigned to the LB

どうも静的アドレスがグローバルのため発生しているみたいで、Serviceにはグローバルで作成した静的アドレスは使えない、、、
なので、ingressのリソースを作成する必要がある

というより、そもそもGKEの場合、Service(type: LoadBalancer)はL4のロードバランサなので、HTTPSロードバランサにはIngressを作成する必要があった、、すごい今更すぎた、、

ステップ8:さらに気を取り直して、Ingress作成(実はここからがステップ1)

まずはIngressを作成すると共に、ServiceはNodePortにする

Ingress
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: default
  annotations:
    kubernetes.io/ingress.global-static-ip-name: ロードバランサのIP
    networking.gke.io/managed-certificates: 証明書の名前
spec:
(以下省略)
Service
apiVersion: v1
kind: Service
metadata:
  name: default
spec:
  type: NodePort
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  - name: https
    protocol: TCP
    port: 443
    targetPort: 80
(以下省略)

ステップ9:証明書のリソースを作成

ManagedCertificate オブジェクトを作成する

apiVersion: networking.gke.io/v1beta2
kind: ManagedCertificate
metadata:
  name: sports-memory
spec:
  domains:
    - ドメイン名

ステップ10:Cloud DNSにロードバランサのIPを設定

ステップ8とステップ9で作成したリソースをデプロイすることで、ロードバランサも自動で作成される
この時点では証明書のIPとドメインのIPが異なるので、まだ証明書はPROVISIONINGのままで、https通信もできない

ロードバランサのIPアドレスをCloud DNSのAレコードに設定することで、証明書がACTIVEになる

そして、待ちに待った通信保護マークがついた!!
スクリーンショット 2020-07-26 0.42.55.png

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1