GitLabチャートのシークレットを設定する
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab Self-Managed
GitLabを運用するには、さまざまなシークレットが必要です:
GitLabコンポーネント:
- レジストリ認証認証局証明書
- GitLab ShellのSSHホストキーと証明書
- 個々のGitLabサービス用パスワード
- GitLab PagesのTLS証明書
オプションの外部サービス:
- SMTPサーバー
- LDAP
- OmniAuth
- 受信メール用IMAP(mail_roomサービス経由)
- サービスデスクのメール用IMAP(mail_roomサービス経由)
- 受信メール用OAuth2を使用したMicrosoft Graph(mail_roomサービス経由)
- サービスデスクのメール用OAuth2を使用したMicrosoft Graph(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これらの証明書を含むシークレットを作成します。registry-auth.keyおよびregistry-auth.crtキーを<name>-registry-secretシークレット内に作成します。<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設定によって参照されます。
レジストリ機密通知ヘッダー
詳細については、レジストリ通知の構成に関するドキュメントを確認してください。
シークレットの内容は、項目が1つだけの場合でも、項目のリストである必要があります。コンテンツが単なる文字列である場合、チャートは必要に応じてリストに変換しません。
値RandomFooBarを持つregistry-authorization-headerシークレットが作成される例を考えてみましょう。
kubectl create secret generic registry-authorization-header --from-literal=value="[RandomFooBar]"デフォルトでは、シークレット内で使用されるキーは「value」です。ただし、ユーザーは別のキーを使用できますが、ヘッダーマップ項目でkeyとして指定されていることを確認する必要があります。
SSHホストキー
OpenSSH認証局-キーペアを生成します:
mkdir -p hostKeys
ssh-keygen -t rsa -f hostKeys/ssh_host_rsa_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エラーが表示されます。
初期エンタープライズライセンス
この方法は、インストール時にのみライセンスを追加します。Webインターフェースの管理者エリアを使用して、ライセンスを更新またはアップグレードします。
GitLabインスタンスのエンタープライズライセンスを格納するための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キーを変更することもできます。
初期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シークレット
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シークレット
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-f0-9' | head -c 128)
otp_key_base: $(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-f0-9' | head -c 128)
db_key_base: $(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-f0-9' | head -c 128)
encrypted_settings_key_base: $(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-f0-9' | head -c 128)
openid_connect_signing_key: |
$(openssl genrsa 2048 | awk '{print " " $0}')
active_record_encryption_primary_key:
- $(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32)
active_record_encryption_deterministic_key:
- $(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32)
active_record_encryption_key_derivation_salt: $(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32)
EOF
kubectl create secret generic <name>-rails-secret --from-file=secrets.ymlこのシークレットは、global.railsSecrets.secret設定によって参照されます。
データベース暗号化キーが含まれているため、このシークレットをローテーションすることは推奨されません。シークレットがローテーションされると、シークレットファイルが失われた場合と同じ動作が示されます。
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シークレット
このチャートをKASサブチャートをインストールせずにデプロイする場合でも、GitLab RailsにはKASのシークレットが存在する必要があります。それでも、以下の手順に従ってこのシークレットを手動で作成するか、チャートにシークレットを自動生成させることができます。
<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.secret設定によって参照されます。
GitLab KAS APIシークレット
チャートにシークレットを自動生成させるか、このシークレットを手動で作成できます(<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 KAS WebSocketトークンシークレット
チャートにシークレットを自動生成させるか、このシークレットを手動で作成できます(<name>をリリースの名前に置き換えます):
kubectl create secret generic <name>-kas-websocket-token --from-literal=kas_websocket_token_secret=$(head -c 72 /dev/urandom | base64 -w0)このシークレットは、gitlab.kas.websocketToken.secret設定によって参照されます。
GitLab推奨レビュアーのシークレット
レビュアーの推奨シークレットは自動的に作成され、GitLab.comでのみ使用されます。このシークレットは、GitLab Self-Managedでは不要です。
GitLab Railsには、推奨レビュアーのシークレットが存在する必要があります。チャートにシークレットを自動生成させるか、このシークレットを手動で作成できます(<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パスワードの変更
デフォルトのHelm Chart設定は本番環境を対象としたものではありません。これには、バンドルされたPostgreSQLサブチャートも含まれます。
バンドルされたPostgreSQLサブチャートは、データベースが最初に作成されたときに、シークレットからのパスワードを使用してデータベースを構成するだけです。既存のデータベースでパスワードを変更するには、追加の手順を実行する必要があります。
この操作を行うと、変更が行われている間、ユーザーは中断されることに注意してください。
PostgreSQLシークレットをローテーションするには:
PostgreSQLシークレットの一般的なシークレットのローテーション手順を完了します。
PostgreSQLポッドにExecして、データベース内のパスワードを更新します:
# 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 '$(echo $POSTGRES_POSTGRES_PASSWORD)' ; ALTER USER gitlab WITH PASSWORD '$(echo $POSTGRES_PASSWORD)' ; ALTER USER registry WITH PASSWORD '$(echo $REGISTRY_POSTGRES_PASSWORD)'" | psql -U postgres -d gitlabhq_production -f - sed -i 's/^\(local .*\)trust$/\1md5/' /opt/bitnami/postgresql/conf/pg_hba.conf pg_ctl reloadメモ: レジストリユーザーのパスワードの更新は、レジストリメタデータデータベース機能が有効になっている場合にのみ必要です。レジストリユーザーが存在しない場合、
ALTER USER registryコマンドはエラーを生成しますが、他のパスワードの更新には影響しません。新しいポッドに新しいシークレットが読み込まれ、データベースに接続できるように、
gitlab-exporter、postgresql、toolbox、sidekiq、webservice、registryのポッドをkubectl delete podコマンドを使用して削除します。
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 Webサービスのポッドで共有される、ランダムな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設定によって参照されます。
外部サービス
一部のチャートには、自動生成できない機能を有効にするための追加のシークレットがあります。
OmniAuth
デプロイされたGitLabでOmniAuthプロバイダーの使用を有効にするには、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を使用して、パスワードを設定に挿入します。
Helmプロパティを設定する場合は、Secret名を使用し、_実際のパスワード_は使用しないでください。
SMTPパスワード
認証を必要とするSMTPサーバーを使用している場合は、パスワードをKubernetesのシークレットに保存します。
kubectl create secret generic smtp-password --from-literal=password=yourpasswordhere次に、--set global.smtp.password.secret=smtp-passwordをHelmコマンドで使用します。
Helmプロパティを設定する場合は、Secret名を使用し、_実際のパスワード_は使用しないでください。
受信メールのIMAPパスワード
GitLabは、メールへの受信アクセスに、アプリのパスワード、トークン、IMAPパスワードなどの認証文字列を使用します。
GitLabの受信メールドキュメントでメールプロバイダーを見つけ、必要な認証文字列をKubernetesのシークレットとして設定します。
kubectl create secret generic incoming-email-password --from-literal="password=auth_string_for_your_provider_here"次に、--set global.appConfig.incomingEmail.password.secret=incoming-email-passwordをHelmコマンドで使用し、ドキュメントで指定されているその他の必要な設定と一緒に使用します。
Helmプロパティを設定する場合は、Secret名を使用し、_実際のパスワード_は使用しないでください。
サービスデスクのメールのIMAPパスワード
GitLabは、サービスデスクのメールへのアクセスに、アプリのパスワード、トークン、IMAPパスワードなどの認証文字列を使用します。
GitLabの受信メールドキュメントでメールプロバイダーを見つけ、必要な認証文字列をKubernetesのシークレットとして設定します。
kubectl create secret generic service-desk-email-password --from-literal="password=auth_string_for_your_provider_here"次に、--set global.appConfig.serviceDeskEmail.password.secret=service-desk-email-passwordをHelmコマンドで使用し、ドキュメントで指定されているその他の必要な設定と一緒に使用します。
Helmプロパティを設定する場合は、Secret名を使用し、_実際のパスワード_は使用しないでください。
GitLabの受信メール認証トークン
受信メールがWebhook配信方法を使用するように設定されている場合、mail_roomサービスとwebserviceの間に共有シークレットが必要です。これは、長さが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サービスデスクのメール認証トークン
サービスデスクのメールがWebhook配信方法を使用するように設定されている場合、mail_roomサービスとwebserviceの間に共有シークレットが必要です。これは、長さが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基本認証パスワード
このシークレットの自動生成をチャートに任せるか、手動で作成できます(<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が受信メールにアクセスできるようにするには、KubernetesのシークレットにIMAPアカウントのパスワードを保存します:
kubectl create secret generic incoming-email-client-secret --from-literal=secret=your-secret-here次に、--set global.appConfig.incomingEmail.clientSecret.secret=incoming-email-client-secretをHelmコマンドで使用し、ドキュメントで指定されているその他の必要な設定と一緒に使用します。
Helmプロパティを設定する場合は、Secret名を使用し、_実際のパスワード_は使用しないでください。
サービスデスクのメールのMicrosoft Graphクライアントのシークレットキー
GitLabがサービスデスクのメールにアクセスできるようにするには、KubernetesのシークレットにIMAPアカウントのパスワードを保存します:
kubectl create secret generic service-desk-email-client-secret --from-literal=secret=your-secret-here次に、--set global.appConfig.serviceDeskEmail.clientSecret.secret=service-desk-email-client-secretをHelmコマンドで使用し、ドキュメントで指定されているその他の必要な設定と一緒に使用します。
Helmプロパティを設定する場合は、Secret名を使用し、_実際のパスワード_は使用しないでください。
送信メールのMicrosoft Graphクライアントのシークレットキー
パスワードをKubernetesのシークレットに保存します:
kubectl create secret generic microsoft-graph-mailer-client-secret --from-literal=secret=your-secret-here次に、--set global.appConfig.microsoft_graph_mailer.client_secret.secret=microsoft-graph-mailer-client-secretをHelmコマンドで使用します。
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.keyNameとglobal.email.smime.certNameの値を調整する必要があります。
S/MIME設定は、values.yamlファイルまたはコマンドラインから設定できます。--set global.email.smime.enabled=trueを使用してS/MIMEを有効にし、--set global.email.smime.secretName=smime-certificateを使用してS/MIME証明書を含むシークレットを指定します。
スマートカード認証
スマートカード認証は、カスタム認証局(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のデプロイに進むことができます。
シークレットのローテーション
セキュリティ上の目的で必要な場合は、シークレットをローテーションできます。
- 現在のシークレットをバックアップします。
- 便宜上、ローテーションする各シークレットについて、手動シークレット作成手順に従って、
-v2(例:gitlab-shell-host-keys-v2)というサフィックスが付いた新しいシークレットを作成します。 - 新しいシークレット名を指すように、
values.yamlファイル内のシークレットキーを更新します。ほとんどのシークレット名は、手動シークレット作成セクションのそれぞれのシークレットの下に記載されています。 - 更新された
values.yamlファイルを使用して、GitLabチャートリリースをアップグレードします。 - PostgreSQLのシークレットをローテーションする場合は、追加の手順でローテーションを完了させる必要があります。
- GitLabが期待どおりに動作していることを確認します。問題がなければ、古いシークレットを削除しても安全です。