GitLabチャートのシークレット設定

GitLabのオペレーションには様々なシークレットが必要です:

GitLabコンポーネント:

  • レジストリ認証証明書
  • GitLabシェル用のSSHホストキーと証明書
  • 個々のGitLabサービスのパスワード
  • GitLab PagesのTLS証明書

オプションの外部サービス

  • SMTPサーバー
  • LDAP
  • オムニ認証
  • 受信メールの IMAP (mail_room サービス経由)
  • サービスデスクのメール用IMAP(mail_roomサービス経由)
  • メール受信用のOAuth2付きMicrosoft Graph(mail_roomサービス経由)
  • Microsoft Graph with OAuth2 for Service Desk メール(mail_room サービス経由)
  • OAuth2 を使用した Microsoft Graph による送信メール
  • S/MIME証明書
  • スマートカード認証
  • OAuthインテグレーション

手動で提供されないシークレットは、ランダムな値で自動生成されます。HTTPS 証明書の自動生成は Let’s Encrypt が提供します。

自動生成されたシークレットを利用するには、次の手順に進んでください。

独自のシークレットを指定するには、手動シークレット作成に進みます。

手動シークレット作成(オプション)

このドキュメントの前のステップに従った場合は、リリース名としてgitlab を使用してください。

レジストリ認証証明書

GitLabとレジストリ間の通信はIngressの後ろで行われるので、ほとんどの場合、この通信には自己署名証明書を使えば十分です。このトラフィックがネットワーク上に公開される場合は、公開された有効な証明書を生成する必要があります。

以下の例では、自己署名証明書が必要だと仮定しています。

証明書と鍵のペアを生成します:

mkdir -p certs
openssl req -new -newkey rsa:4096 -subj "/CN=gitlab-issuer" -nodes -x509 -keyout certs/registry-example-com.key -out certs/registry-example-com.crt

これらの証明書を含むシークレットを作成します。<name>-registry-secret シークレットの内部にregistry-auth.keyregistry-auth.crt のキーを作成します。<name> をリリース名に置き換えてください。

kubectl create secret generic <name>-registry-secret --from-file=registry-auth.key=certs/registry-example-com.key --from-file=registry-auth.crt=certs/registry-example-com.crt

このシークレットはglobal.registry.certificate.secret の設定で参照されます。

レジストリ機密通知ヘッダ

詳細はレジストリ通知の設定に関するドキュメントを参照してください。

シークレットコンテンツはアイテムのリストでなければなりません。内容が文字列の場合、Chart はそれをリストに変換しません

RandomFooBar という値を持つregistry-authorization-header シークレットが作成された例を考えてみましょう。

kubectl create secret generic registry-authorization-header --from-literal=value="[RandomFooBar]"

デフォルトでは、secretの中で使われるキーは “value “です。しかし、ユーザーは別のキーを使うことができます。しかし、ヘッダーマップアイテムの下でkey

SSHホストキー

OpenSSH 証明書と鍵のペアを生成します:

mkdir -p hostKeys
ssh-keygen -t rsa  -f hostKeys/ssh_host_rsa_key -N ""
ssh-keygen -t dsa  -f hostKeys/ssh_host_dsa_key -N ""
ssh-keygen -t ecdsa  -f hostKeys/ssh_host_ecdsa_key -N ""
ssh-keygen -t ed25519  -f hostKeys/ssh_host_ed25519_key -N ""

これらの証明書を含むシークレットを作成します。<name> をリリース名に置き換えてください。

kubectl create secret generic <name>-gitlab-shell-host-keys --from-file hostKeys

このシークレットはglobal.shell.hostKeys.secret の設定で参照されます。

このシークレットがローテートされると、すべての SSH クライアントはhostname mismatch エラーを見ることになります。

初期エンタープライズライセンス

caution
この方法では、インストール時にのみライセンスが追加されます。ライセンスの更新やアップグレードには、ウェブユーザーインターフェースの管理エリアを使用します。

GitLabインスタンスのEnterpriseライセンスを保存するためのKubernetesシークレットを作成します。<name> をリリース名に置き換えてください。

kubectl create secret generic <name>-gitlab-license --from-file=license=/tmp/license.gitlab

その後、--set global.gitlab.license.secret=<name>-gitlab-license を使って設定にライセンスを注入します。

また、global.gitlab.license.key オプションを使って、license secret でライセンスを指すデフォルトのlicense キーを変更することもできます。

初期 root パスワード

初期rootパスワードを保存するためのKubernetesシークレットを作成します。パスワードは6文字以上でなければなりません。<name> をリリース名に置き換えてください。

kubectl create secret generic <name>-gitlab-initial-root-password --from-literal=password=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32)

Redisのパスワード

Redis用のランダムな64文字の英数字のパスワードを生成します。<name> をリリース名に置き換えてください。

kubectl create secret generic <name>-redis-secret --from-literal=secret=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64)

すでに存在するRedisクラスターでデプロイする場合は、ランダムに生成したパスワードではなく、base64エンコードされたRedisクラスターにアクセスするためのパスワードを使用してください。

このシークレットはglobal.redis.auth.secret の設定で参照されます。

GitLab Shellのシークレット

GitLab Shell用のランダムな64文字の英数字のシークレットを生成します。<name> をリリース名に置き換えてください。

kubectl create secret generic <name>-gitlab-shell-secret --from-literal=secret=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64)

このシークレットはglobal.shell.authToken.secret の設定で参照されます。

シークレット

Gitaly用のランダムな64文字の英数字トークンを生成します。<name> をリリース名に置き換えてください。

kubectl create secret generic <name>-gitaly-secret --from-literal=token=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64)

このシークレットはglobal.gitaly.authToken.secret の設定で参照されます。

シークレット

Praefect用のランダムな64文字の英数字トークンを生成します。<name> をリリース名に置き換えてください:

kubectl create secret generic <name>-praefect-secret --from-literal=token=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64)

このシークレットはglobal.praefect.authToken.secret の設定で参照されます。

GitLab Railsのシークレット

<name> をリリース名に置き換えてください。

cat << EOF > secrets.yml
production:
  secret_key_base: $(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 128)
  otp_key_base: $(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 128)
  db_key_base: $(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 128)
  encrypted_settings_key_base: $(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 128)
  openid_connect_signing_key: |
$(openssl genrsa 2048 | awk '{print "    " $0}')
  ci_jwt_signing_key: |
$(openssl genrsa 2048 | awk '{print "    " $0}')
EOF

kubectl create secret generic <name>-rails-secret --from-file=secrets.yml

このシークレットはglobal.railsSecrets.secret の設定で参照されます。

このシークレットにはデータベースの暗号化キーが含まれているので、ローテーションすることは推奨されません。シークレットをローテートした場合、シークレットファイルが失われたときと同じ動作になります。

note
encrypted_settings_key_base は GitLab13.7で追加され、GitLab14.0で必要になります。

GitLab Workhorseのシークレット

Workhorseのシークレットを生成します。32文字でbase64エンコードされている必要があります。<name> をリリース名に置き換えてください。

kubectl create secret generic <name>-gitlab-workhorse-secret --from-literal=shared_secret=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32 | base64)

このシークレットはglobal.workhorse.secret の設定で参照されます。

GitLab Runner シークレット

<name> をリリース名に置き換えてください。

kubectl create secret generic <name>-gitlab-runner-secret --from-literal=runner-registration-token=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64)

このシークレットはgitlab-runner.runners.secret の設定で参照されます。

GitLab KAS シークレット

GitLab Railsでは、KASサブチャートをインストールせずにこのチャートをデプロイする場合でも、KAS用のシークレットが必要です。それでも、以下の手順に従って手動でこのシークレットを作成することもできますし、Chartがシークレットを自動生成することもできます。

<name> をリリース名に置き換えてください。

kubectl create secret generic <name>-gitlab-kas-secret --from-literal=kas_shared_secret=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32 | base64)

このシークレットはglobal.appConfig.gitlab_kas.key の設定で参照されます。

GitLab KAS API シークレット

シークレットの自動生成はChartに任せることもできますし、手動で作成することもできます(<name> をリリース名に置き換えてください):

kubectl create secret generic <name>-kas-private-api --from-literal=kas_private_api_secret=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32 | base64)

このシークレットはgitlab.kas.privateApi.secret の設定で参照されます。

GitLab 推奨レビュアーシークレット

note
Suggested Reviewersシークレットは自動的に作成され、GitLab SaaSでのみ使用されます。セルフマネジメントのGitLabインスタンスではこのシークレットは必要ありません。

GitLab Railsでは、Suggested Reviewersのシークレットが必要です。シークレットの自動生成はChartに任せることもできますし、手動でこのシークレットを作成することもできます(<name> をリリース名に置き換えてください):

kubectl create secret generic <name>-gitlab-suggested-reviewers --from-literal=suggested_reviewers_secret=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32 | base64)

このシークレットはglobal.appConfig.suggested_reviewers.secret の設定で参照されます。

MinIOシークレット

MinIO用のランダムな20文字および64文字の英数字キーのセットを生成します。<name> をリリース名に置き換えてください。

kubectl create secret generic <name>-minio-secret --from-literal=accesskey=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 20) --from-literal=secretkey=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64)

このシークレットはglobal.minio.credentials.secret の設定で参照されます。

PostgreSQLパスワード

ランダムな64文字の英数字のパスワードを生成します。<name> をリリース名に置き換えてください。

kubectl create secret generic <name>-postgresql-password \
    --from-literal=postgresql-password=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64) \
    --from-literal=postgresql-postgres-password=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64)

このシークレットはglobal.psql.password.secret の設定で参照されます。

バンドルされているPostgreSQLサブチャートのPostgreSQLパスワードの変更

caution
デフォルトのHelmチャートの設定は、バンドルされたPostgreSQLサブチャートを含む本番環境向けではありません。

バンドルされているPostgreSQLサブチャートは、データベースの初期作成時にシークレットのパスワードでデータベースを設定するだけです。既存のデータベースのパスワードを変更するには、追加の手順が必要です。

このオペレーションは、変更が行われている間、ユーザを混乱させることに注意してください。

PostgreSQLのシークレットをローテーションします:

  1. PostgreSQLのシークレットの一般的なローテーションの手順を完了してください。
  2. PostgreSQLポッドに入り、データベースのパスワードを更新します:

    # Exec into the PostgreSQL pod
    kubectl exec -it <name>-postgresql-0 -- sh
       
    # Inside the pod, update the passwords in the database
    sed -i 's/^\(local .*\)md5$/\1trust/' /opt/bitnami/postgresql/conf/pg_hba.conf
    pg_ctl reload ; sleep 1
    echo "ALTER USER postgres WITH PASSWORD '$(cat $POSTGRES_POSTGRES_PASSWORD_FILE)' ; ALTER USER gitlab WITH PASSWORD '$(cat $POSTGRES_PASSWORD_FILE)'" | psql -U postgres -d gitlabhq_production -f -
    sed -i 's/^\(local .*\)trust$/\1md5/' /opt/bitnami/postgresql/conf/pg_hba.conf
    pg_ctl reload
    
  3. kubectl delete pod コマンドを使用してgitlab-exporter,postgresql,toolbox,sidekiq,webservice ポッドを削除し、新しいポッドに新しいシークレットをロードしてデータベースへの接続を許可します。

GitLab Pages シークレット

GitLab Pagesのシークレットを生成します。32文字でbase64エンコードされている必要があります。<name> をリリース名に置き換えてください。

kubectl create secret generic <name>-gitlab-pages-secret --from-literal=shared_secret=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32 | base64)

このシークレットはglobal.pages.apiSecret.secret の設定で参照されます。

レジストリ HTTP シークレット

すべてのレジストリポッドで共有されるランダムな 64 文字の英数字キーを生成します。<name> をリリース名に置き換えてください。

kubectl create secret generic <name>-registry-httpsecret --from-literal=secret=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64 | base64)

このシークレットはglobal.registry.httpSecret.secret の設定で参照されます。

レジストリ通知シークレット

すべてのレジストリポッドとGitLabウェブサービスポッドで共有されるランダムな32文字の英数字のキーを生成します。<name> をリリース名に置き換えてください。

kubectl create secret generic <name>-registry-notification --from-literal=secret=[\"$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32)\"]

このシークレットはglobal.registry.notificationSecret.secret の設定で参照されます。

Praefect DB パスワード

ランダムな64文字の英数字のパスワードを生成します。<name> をリリース名に置き換えてください:

kubectl create secret generic <name>-praefect-dbsecret \
    --from-literal=secret=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64) \

このシークレットはglobal.praefect.dbSecret の設定で参照されます。

外部サービス

一部のChartには、自動生成できない機能を有効にするためのシークレットがあります。

オムニ認証

デプロイしたGitLabでOmniAuth Providersを使えるようにするには、Globalsチャートの指示に従ってください。

LDAP パスワード

LDAPサーバーとの接続にパスワード認証が必要な場合は、Kubernetesシークレットにパスワードを保存する必要があります。

kubectl create secret generic ldap-main-password --from-literal=password=yourpasswordhere

その後、--set global.appConfig.ldap.servers.main.password.secret=ldap-main-password を使用して設定にパスワードを注入します。

note
Helm プロパティを設定するときは、実際のパスワードではなくSecret 名を使用します。

SMTP パスワード

認証が必要なSMTPサーバーを使用している場合は、Kubernetesシークレットにパスワードを保存します。

kubectl create secret generic smtp-password --from-literal=password=yourpasswordhere

その後、Helmコマンドで--set global.smtp.password.secret=smtp-password

note
Helm プロパティを設定するときは、実際のパスワードではなくSecret 名を使用します。

受信メールのIMAPパスワード

GitLabが受信メールにアクセスできるようにするには、IMAPアカウントのパスワードをKubernetesのシークレットに保存します。

kubectl create secret generic incoming-email-password --from-literal=password=yourpasswordhere

それから、ドキュメントで指定されている他の必要な設定と一緒にHelmコマンドで--set global.appConfig.incomingEmail.password.secret=incoming-email-password

note
Helm プロパティを設定するときは、実際のパスワードではなくSecret 名を使用します。

サービスデスクのメールのIMAPパスワード

GitLabがservice_deskのメールにアクセスできるようにするには、IMAPアカウントのパスワードをKubernetesのシークレットに保存します。

kubectl create secret generic service-desk-email-password --from-literal=password=yourpasswordhere

それから、ドキュメントで指定されている他の必要な設定と一緒にHelmコマンドで--set global.appConfig.serviceDeskEmail.password.secret=service-desk-email-password

note
Helm プロパティを設定するときは、実際のパスワードではなくSecret 名を使用します。

GitLab 受信メール認証トークン

受信メールがWebhook配信を使うように設定されている場合、mail_roomサービスとWebサービスの間で共有シークレットが必要です。これは32文字の長さで、base64エンコードされている必要があります。<name> をリリース名に置き換えてください。

kubectl create secret generic <name>-incoming-email-auth-token --from-literal=authToken=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32 | base64)

このシークレットはglobal.incomingEmail.authToken の設定で参照されます。

GitLab Service Desk メール認証トークン

Service DeskのメールがWebhook配信メソッドを使用するように設定されている場合、mail_roomサービスとWebサービスの間に共有シークレットが必要です。これは32文字の長さで、base64エンコードされていなければなりません。<name> をリリース名に置き換えてください。

kubectl create secret generic <name>-service-desk-email-auth-token --from-literal=authToken=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32 | base64)

このシークレットはglobal.serviceDeskEmail.authToken の設定で参照されます。

Zoektベーシック認証パスワード

シークレットの自動生成はChartに任せることもできますし、手動で作成することもできます(<name> をリリース名に置き換えてください):

password=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32 | base64)
kubectl create secret generic <name>-zoekt-basicauth --from-literal=gitlab_username=gitlab --from-literal=gitlab_password="$password"

このシークレットはgitlab.zoekt.gateway.basicAuth.secretName の設定で参照されます。

Microsoft Graph クライアント受信メールのシークレット

GitLabが受信メールにアクセスできるようにするには、IMAPアカウントのパスワードをKubernetesのシークレットに保存します:

kubectl create secret generic incoming-email-client-secret --from-literal=secret=your-secret-here

それから、ドキュメントで指定されている他の必要な設定とともに、Helmコマンドで--set global.appConfig.incomingEmail.clientSecret.secret=incoming-email-client-secret

note
Helm プロパティを設定するときは、実際のパスワードではなくSecret 名を使用します。

Service Deskメール用のMicrosoft Graphクライアントシークレット

GitLabがservice_deskのメールにアクセスできるようにするには、IMAPアカウントのパスワードをKubernetesのシークレットに保存します:

kubectl create secret generic service-desk-email-client-secret --from-literal=secret=your-secret-here

それから、ドキュメントで指定されている他の必要な設定とともに、Helmコマンドで--set global.appConfig.serviceDeskEmail.clientSecret.secret=service-desk-email-client-secret

note
Helm プロパティを設定するときは、実際のパスワードではなくSecret 名を使用します。

送信メール用のMicrosoft Graphクライアントのシークレット

パスワードをKubernetesシークレットに保存します:

kubectl create secret generic microsoft-graph-mailer-client-secret --from-literal=secret=your-secret-here

その後、Helmコマンドで--set global.appConfig.microsoft_graph_mailer.client_secret.secret=microsoft-graph-mailer-client-secret

note
Helm プロパティを設定するときは、実際のパスワードではなくSecret 名を使用します。

S/MIME 証明書

送信メールメッセージは、S/MIME標準を使用してデジタル署名することができます。S/MIME証明書はTLSタイプのシークレットとしてKubernetesのシークレットに保存する必要があります。

kubectl create secret tls smime-certificate --key=file.key --cert file.crt

不透明タイプとして既存のシークレットがある場合は、global.email.smime.keyNameglobal.email.smime.certName の値を特定のシークレット用に調整する必要があります。

S/MIME 設定はvalues.yaml ファイルまたはコマンドラインで設定できます。S/MIMEを有効にするには--set global.email.smime.enabled=true 、S/MIME証明書を含むシークレットを指定するには--set global.email.smime.secretName=smime-certificate

スマートカード認証

スマートカード認証では、カスタム認証局((CA) )を使用してクライアント証明書に署名します。クライアント証明書が有効かどうかを確認するために、このカスタム CA の証明書を Web サービスポッドに注入する必要があります。これは k8s シークレットとして提供されます。

kubectl create secret generic <secret name> --from-file=ca.crt=<path to CA certificate>

証明書が格納されているシークレット内部のキー名はca.crt でなければなりません。

OAuthインテグレーション

GitLab Pages のような様々なサービスの OAuth インテグレーションを設定するには、OAuth 認証情報を含むシークレットが必要です。シークレットには、アプリ ID (デフォルトではappid キーの下に格納されています) とアプリの秘密 (デフォルトではappsecret キーの下に格納されています) を含める必要があります。どちらも英数字の文字列で、64 文字以上であることが推奨されます。

kubectl create secret generic oauth-gitlab-pages-secret --from-literal=appid=<app id> --from-literal=appsecret=<app secret>

このシークレットはglobal.oauth.<service name>.secret の設定で指定できます。appid およびappsecret 以外のキーを使用する場合は、global.oauth.<service name>.appIdKey およびglobal.oauth.<service name>.appSecretKey の設定を使用して指定できます。

次のステップ

すべてのシークレットが生成され、保存されたら、GitLabのデプロイを進めることができます。

シークレットのローテーション

セキュリティのために必要であれば、シークレットをローテーションすることができます。

  1. 現在のシークレットをバックアップしてください。
  2. 便宜上、ローテーションしたい各シークレットの手動シークレット作成手順に従って、サフィックスが-v2 (例えばgitlab-shell-host-keys-v2) である新しいシークレットを作成してください。
  3. values.yaml ファイルのシークレットキーを更新し、新しいシークレット名を指すようにします。ほとんどのシークレット名は、手動シークレット作成セクションの各シークレットの下に記載されています。
  4. 更新したvalues.yaml ファイルで GitLab Chart リリースをアップグレードしてください。
  5. PostgreSQLのシークレットをローテーションする場合、ローテーションを完了するための追加のステップがあります。
  6. GitLab が期待通りに動いていることを確認します。うまくいっていれば、古いシークレットを削除しても大丈夫です。