GitLabチャートのTLSを設定する

このチャートは、NGINX Ingressコントローラーを使用してTLS終了を実行できます。デプロイメントのTLS証明書を取得する方法を選択できます。詳細については、グローバルIngress設定を参照してください。

オプション1: cert-managerとLet’s Encrypt

Let’s Encryptは、無料で自動化されたオープンCAです。証明書は、さまざまなツールを使用して自動的にリクエストできます。このチャートには、一般的な選択肢であるcert-managerと統合する準備ができています。

すでにcert-managerを使用している場合は、global.ingress.annotationsを使用して、cert-managerデプロイメントに適切な注釈を設定できます。

クラスターにcert-managerがまだインストールされていない場合は、このチャートの依存関係としてインストールして構成できます。

内部cert-managerとIssuer

helm repo update
helm dep update
helm install gitlab gitlab/gitlab \
  --set certmanager-issuer.email=you@example.com

cert-managerのインストールはinstallCertmanager設定で制御され、チャートでの使用はglobal.ingress.configureCertmanager設定で制御されます。これらは両方ともtrueがデフォルトであるため、 メールのみデフォルトで指定する必要があります。

外部cert-managerと内部Issuer

外部のcert-managerを使用できますが、このチャートの一部としてを提供します。

helm install gitlab gitlab/gitlab \
  --set installCertmanager=false \
  --set certmanager-issuer.email=you@example.com \
  --set global.ingress.annotations."kubernetes\.io/tls-acme"=true

外部cert-managerとIssuer（外部）

外部cert-managerおよびIssuerリソースを使用するには、いくつかの項目を指定して、自己署名証明書がアクティブにならないようにする必要があります。

1. 外部cert-managerをアクティブにするための注釈（詳細については、ドキュメントを参照してください）
2. 各サービスのTLSシークレットの名前（これにより、自己署名動作が無効になります）

helm install gitlab gitlab/gitlab \
  --set installCertmanager=false \
  --set global.ingress.configureCertmanager=false \
  --set global.ingress.annotations."kubernetes\.io/tls-acme"=true \
  --set gitlab.webservice.ingress.tls.secretName=RELEASE-gitlab-tls \
  --set registry.ingress.tls.secretName=RELEASE-registry-tls \
  --set minio.ingress.tls.secretName=RELEASE-minio-tls \
  --set gitlab.kas.ingress.tls.secretName=RELEASE-kas-tls

オプション2: 独自のワイルドカード証明書を使用する

完全な証明書チェーンとキーをSecretとしてクラスターに追加します。例:

kubectl create secret tls <tls-secret-name> --cert=<path/to-full-chain.crt> --key=<path/to.key>

オプションを含めます

helm install gitlab gitlab/gitlab \
  --set installCertmanager=false \
  --set global.ingress.configureCertmanager=false \
  --set global.ingress.tls.secretName=<tls-secret-name>

AWS ACMを使用して証明書を管理する

AWS ACMを使用してワイルドカード証明書を作成する場合、ACM証明書をダウンロードできないため、シークレット経由で指定することはできません。代わりに、nginx-ingress.controller.service.annotationsを使用して指定します:

nginx-ingress:
  controller:
    service:
      annotations:
        ...
        service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:{region}:{user id}:certificate/{id}

オプション3: サービスごとに個別の証明書を使用する

完全な証明書チェーンをシークレットとしてクラスタに追加し、それらのシークレット名を各Ingressに渡します。

helm install gitlab gitlab/gitlab \
  --set installCertmanager=false \
  --set global.ingress.configureCertmanager=false \
  --set global.ingress.tls.enabled=true \
  --set gitlab.webservice.ingress.tls.secretName=RELEASE-gitlab-tls \
  --set registry.ingress.tls.secretName=RELEASE-registry-tls \
  --set minio.ingress.tls.secretName=RELEASE-minio-tls \
  --set gitlab.kas.ingress.tls.secretName=RELEASE-kas-tls

オプション4: 自動生成された自己署名ワイルドカード証明書を使用する

これらのチャートは、自動生成された自己署名ワイルドカード証明書を提供する機能も提供します。これは、Let’s Encryptがオプションではない環境では役立ちますが、SSLによるセキュリティは依然として必要です。この機能は、共有シークレットジョブによって提供されます。

helm install gitlab gitlab/gitlab \
  --set installCertmanager=false \
  --set global.ingress.configureCertmanager=false \
  --set gitlab-runner.install=false

次に、shared-secretsジョブは、CA証明書、ワイルドカード証明書、および外部からアクセス可能なすべてのサービスで使用するための証明書チェーンを生成します。これらを含むシークレットは、RELEASE-wildcard-tls、RELEASE-wildcard-tls-ca、およびRELEASE-wildcard-tls-chainになります。RELEASE-wildcard-tls-caには、デプロイされたGitLabインスタンスにアクセスするユーザーおよびシステムに配布できるパブリックCA証明書が含まれています。RELEASE-wildcard-tls-chainには、GitLab Runnerにgitlab-runner.certsSecretName=RELEASE-wildcard-tls-chainを介して直接使用できるCA証明書とワイルドカード証明書の両方が含まれています。

GitLab PagesのTLS要件

TLSをサポートするGitLab Pagesの場合、*.<pages domain>（<pages domain>のデフォルト値はpages.<base domain>）に適用可能なワイルドカード証明書が必要です。

ワイルドカード証明書が必要なため、cert-managerとLet’s Encryptによって自動的に作成することはできません。そのため、cert-managerはGitLab Pages（gitlab-pages.ingress.configureCertmanager経由）ではデフォルトで無効になっているため、ワイルドカード証明書を含む独自のk8sシークレットを提供する必要があります。global.ingress.annotationsを使用して構成された外部cert-managerがある場合は、gitlab-pages.ingress.annotationsでそのような注釈をオーバーライドすることもできます。

デフォルトでは、このシークレットの名前は<RELEASE>-pages-tlsです。gitlab.gitlab-pages.ingress.tls.secretName設定を使用して、別の名前を指定できます:

helm install gitlab gitlab/gitlab \
  --set global.pages.enabled=true \
  --set gitlab.gitlab-pages.ingress.tls.secretName=<secret name>

トラブルシューティング

このセクションでは、発生する可能性のある問題の考えられる解決策について説明します。

SSL終了エラー

TLSプロバイダーとしてLet’s Encryptを使用しているときに、証明書関連のエラーが発生した場合は、これをデバッグするためのオプションがいくつかあります:

1. 考えられるエラーについて、letsdebugでドメインを確認してください。

2. letsdebugがエラーを返さない場合は、cert-managerに関連する問題があるかどうかを確認してください:

   kubectl describe certificate,order,challenge --all-namespaces

   エラーが表示された場合は、証明書オブジェクトを削除して、新しい証明書のリクエストを強制的にリクエストしてみてください。

3. 上記の方法で解決しない場合は、既存のcert-managerリソースを削除して、cert-managerを再インストールすることを検討してください。内部cert-managerを使用している場合は、名前にcertmanagerが含まれるデプロイメントを削除し、Helm Chartを再インストールします。たとえば、gitlabという名前のリリースを想定します:

   kubectl -n <namespace> delete deployment gitlab-certmanager gitlab-certmanager-cainjector gitlab-certmanager-webhook
   helm upgrade --install -n <namespace> gitlab gitlab/gitlab