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

### はじめに

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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/214984/588bb3ec-eb41-0234-e4ea-1c028252a2b4.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：気を取り直して、新しい静的アドレスを作成

[こちらから](https://cloud.google.com/compute/docs/ip-addresses/reserve-static-external-ip-address?hl=ja)作成する

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

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

<img width="469" alt="スクリーンショット 2020-07-25 15.13.21.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/214984/85c687c5-0444-3c0d-f832-36a671d35729.png">

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

<img width="407" alt="スクリーンショット 2020-07-25 15.19.59.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/214984/a152aa32-bbfc-bf43-aeec-23d3cd7ba9f4.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にする

```yml: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:
（以下省略）
```

```yml: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 オブジェクトを作成する

```yml
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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/214984/6b4eb48b-4473-4f58-fcd9-d1cf0b20dcd6.png)