ScalarDL Auditor のカスタム値ファイルを構成する

このドキュメントでは、ScalarDL Auditor チャートのカスタム値ファイルを作成する方法について説明します。パラメータの詳細を知りたい場合は、ScalarDL Auditor チャートの README を参照してください。

必要な構成

Scalar Envoy 構成

ScalarDL Auditor のカスタム値ファイルで Scalar Envoy 構成を設定する必要があります。これは、ScalarDL Auditor を Kubernetes 環境にデプロイする場合、クライアントリクエストが gRPC リクエストのロードバランサーとして Scalar Envoy 経由で ScalarDL Auditor に送信されるためです。

Scalar Envoy 構成の詳細については、ドキュメント Scalar Envoy のカスタム値ファイルの構成を参照してください。

envoy:
  configurationsForScalarEnvoy:
    ...

auditor:
  configurationsForScalarDLAuditor:
    ...

画像構成

auditor.image.repository を設定する必要があります。コンテナーリポジトリからイメージをプルできるように、必ず ScalarDL Auditor コンテナーイメージを指定してください。

auditor:
  image:
    repository: <SCALARDL_AUDITOR_CONTAINER_IMAGE>

Scalar 製品のコンテナリポジトリの詳細については、Scalar 製品のコンテナイメージを取得する方法を参照してください。

Auditor / データベースの構成

auditor.auditorProperties を設定する必要があります。auditor.properties をこのパラメータに設定してください。ScalarDL Auditor の設定の詳細については、auditor.properties を参照してください。

auditor:
  auditorProperties: |
    scalar.db.contact_points=localhost
    scalar.db.username=cassandra
    scalar.db.password=cassandra
    scalar.db.storage=cassandra
    scalar.dl.auditor.ledger.host=<Host name to access ScalarDL Ledger pods>
    scalar.dl.auditor.private_key_path=/keys/auditor-key-file
    scalar.dl.auditor.cert_path=/keys/auditor-cert-file

キー/証明書の構成

秘密鍵ファイルを scalar.dl.auditor.private_key_path に設定し、証明書ファイルを scalar.dl.auditor.cert_path に設定する必要があります。

秘密鍵ファイルと証明書ファイルも ScalarDL Auditor ポッドにマウントする必要があります。

秘密鍵ファイルと証明書ファイルをマウントする方法の詳細については、ScalarDL Helm Charts のポッドに秘密鍵ファイルと証明書ファイルをマウントするを参照してください。

オプションの構成

リソース構成 (本番環境で推奨)

Kubernetes のリクエストと制限を使用してポッドリソースを制御したい場合は、auditor.resources を使用できます。

商用ライセンスの観点から、Scalar 製品の1つのポッドのリソースは 2vCPU / 4GB メモリに制限されていることに注意してください。また、AWS Marketplace から提供される従量課金制のコンテナを取得する場合、resources.limits で 2vCPU / 4GB を超えるメモリ構成でそれらのコンテナを実行することはできません。この制限を超えると、ポッドは自動的に停止されます。

これらは、Kubernetes のリクエストと制限と同じ構文を使用して構成できます。そのため、Kubernetes の要求と制限の詳細については、公式ドキュメント Resource Management for Pods and Containers を参照してください。

auditor:
  resources:
    requests:
      cpu: 2000m
      memory: 4Gi
    limits:
      cpu: 2000m
      memory: 4Gi

シークレット構成

環境変数を使用して auditor.auditorProperties 内の一部のプロパティ (資格情報など) を設定したい場合は、auditor.secretName を使用して、いくつかの資格情報を含む Secret リソースを指定できます。

たとえば、環境変数を使用してバックエンドデータベースの資格情報 (scalar.db.username および scalar.db.password) を設定でき、これによりポッドの安全性が高まります。

Secret リソースの使用方法の詳細については、ドキュメント Secret リソースを使用して資格情報を環境変数としてプロパティファイルに渡す方法を参照してください。

auditor:
  secretName: "auditor-credentials-secret"

Affinity configurations (Recommended in the production environment)

Kubernetes のアフィニティと反アフィニティを使用してポッドのデプロイメントを制御したい場合は、auditor.affinity を使用できます。

Kubernetes のアフィニティと同じ構文を使用して構成できます。そのため、Kubernetes のアフィニティ設定の詳細については、公式ドキュメント Assigning Pods to Nodes を参照してください。

auditor:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - podAffinityTerm:
            labelSelector:
              matchExpressions:
                - key: app.kubernetes.io/name
                  operator: In
                  values:
                    - scalardl-audit
                - key: app.kubernetes.io/app
                  operator: In
                  values:
                    - auditor
            topologyKey: kubernetes.io/hostname
          weight: 50

Prometheus/Grafana 構成 (運用環境で推奨)

kube-prometheus-stack を使用して ScalarDL Auditor ポッドを監視する場合は、auditor.grafanaDashboard.enabled、auditor.serviceMonitor を使用して、kube-prometheus-stack の ConfigMap、ServiceMonitor、および PrometheusRule リソースをデプロイできます。enabled および auditor.prometheusRule.enabled。

auditor:
  grafanaDashboard:
    enabled: true
    namespace: monitoring
  serviceMonitor:
    enabled: true
    namespace: monitoring
    interval: 15s
  prometheusRule:
    enabled: true
    namespace: monitoring

SecurityContext 設定 (デフォルト値を推奨)

ScalarDL Auditor ポッドに SecurityContext と PodSecurityContext を設定したい場合は、auditor.securityContext と auditor.podSecurityContext を使用できます。

KubernetesのSecurityContextやPodSecurityContextと同じ構文を使用して設定できます。したがって、Kubernetes の SecurityContext および PodSecurityContext 構成の詳細については、公式ドキュメント Configure a Security Context for a Pod or Container を参照してください。

auditor:
  podSecurityContext:
    seccompProfile:
      type: RuntimeDefault
  securityContext:
    capabilities:
      drop:
        - ALL
    runAsNonRoot: true
    allowPrivilegeEscalation: false

TLS 構成 (環境に応じてオプション)

TLS は、次の通信で有効にできます:

• ScalarDL Auditor とクライアント間の通信。
• ScalarDL Ledger と ScalarDL Auditor 間の通信。

証明書管理にはいくつかのオプションがあります。

1. 秘密鍵と証明書ファイルの管理
   1. cert-manager を使用して秘密鍵と証明書ファイルを自動的に管理します。
      • メンテナンスや運用のコストを削減できます。たとえば、cert-manager は証明書の有効期限が切れる前に自動的に更新し、Scalar Helm Chart は秘密鍵と証明書ファイルを Scalar 製品ポッドに自動的にマウントします。
      • cert-manager がサポートしていない CA は使用できません。サポートされている発行元は cert-manager ドキュメントで確認できます。
   2. 秘密鍵と証明書ファイルを手動で管理します。
      • ご自身のお好みの方法で、秘密鍵と証明書ファイルを発行・管理することができます。
      • cert-manager がサポートしていない場合でも、任意の証明書を使用できます。
      • 証明書の有効期限が切れた場合は、シークレットリソースを更新する必要があります。
2. 証明書の種類
   1. 信頼できる CA (サードパーティによる署名付き証明書) を使用します。
      • サードパーティの証明書発行者からの信頼できる証明書を使用できます。
      • パケットを暗号化できます。
      • 信頼できる証明書を発行するには費用を支払う必要があります。
   2. 自己署名証明書を使用します。
      • 証明書発行にかかるコストを削減できます。
      • 証明書の信頼性は信頼できる CA よりも低くなりますが、パケットを暗号化できます。

つまり、次の4つのオプションがあります。

1. 自動管理で自己署名 CA を使用します。
2. 自動管理で信頼できる CA を使用します。
3. 手動管理で自己署名 CA を使用します。
4. 手動管理で信頼できる CA を使用します。

セキュリティ要件に基づいて、どの方法を使用するかを検討する必要があります。各方法のガイダンスと関連ドキュメントについては、次の意思決定ツリーを参照してください。

TLS を有効にする

次の構成を使用して、すべての ScalarDL Auditor 接続で TLS を有効にすることができます。

auditor:
  auditorProperties: |
    ...(omit)...
    scalar.dl.auditor.server.tls.enabled=true
    scalar.dl.auditor.server.tls.cert_chain_path=/tls/scalardl-auditor/certs/tls.crt
    scalar.dl.auditor.server.tls.private_key_path=/tls/scalardl-auditor/certs/tls.key
    scalar.dl.auditor.tls.enabled=true
    scalar.dl.auditor.tls.ca_root_cert_path=/tls/scalardl-ledger/certs/ca.crt
    scalar.dl.auditor.tls.override_authority=envoy.scalar.example.com
  tls:
    enabled: true

秘密鍵と証明書ファイルを使用する

次の構成を使用して、秘密鍵と証明書ファイルを設定できます。

auditor:
  tls:
    enabled: true
    caRootCertSecret: "scalardl-auditor-tls-ca"
    certChainSecret: "scalardl-auditor-tls-cert"
    privateKeySecret: "scalardl-auditor-tls-key"

この場合、次のように、山括弧内の内容を置き換えて、ScalarDL Ledger および ScalarDL Auditor の秘密鍵と証明書ファイルを含むシークレットリソースを作成する必要があります。

kubectl create secret generic scalardl-auditor-tls-ca --from-file=ca.crt=/<PATH_TO_YOUR_CA_CERTIFICATE_FILE_FOR_SCALARDL_AUDITOR> -n <NAMESPACE>
kubectl create secret generic scalardl-auditor-tls-cert --from-file=tls.crt=/<PATH_TO_YOUR_CERTIFICATE_FILE_FOR_SCALARDL_AUDITOR> -n <NAMESPACE>
kubectl create secret generic scalardl-auditor-tls-key --from-file=tls.key=/<PATH_TO_YOUR_PRIVATE_KEY_FILE_FOR_SCALARDL_AUDITOR> -n <NAMESPACE>
kubectl create secret generic scalardl-auditor-tls-ca-for-ledger --from-file=ca.crt=/<PATH_TO_YOUR_CA_CERTIFICATE_FILE_FOR_SCALARDL_LEDGER> -n <NAMESPACE>

秘密鍵と証明書ファイルを準備する方法の詳細については、Scalar 製品の秘密鍵と証明書ファイルを作成する方法を参照してください。

cert-manager で信頼できる CA を使用して秘密鍵と証明書ファイルを管理する

次の構成を使用して、山括弧内の内容を説明に従って置き換えることで、cert-manager で秘密鍵と証明書ファイルを管理できます。

注記

• cert-manager を使用する場合は、cert-manager をデプロイし、Issuers リソースを準備する必要があります。詳細については、cert-manager のドキュメント、インストールおよび発行者構成を参照してください。
• デフォルトでは、Scalar Helm Chart は Scalar 製品の証明書要件を満たす Certificate リソースを作成します。デフォルトの証明書構成が推奨されますが、カスタム証明書構成を使用する場合は、Scalar 製品の証明書要件を満たす必要があります。詳細については、Scalar 製品の秘密鍵と証明書ファイルを作成する方法を参照してください。

auditor:
  tls:
    enabled: true
    certManager:
      enabled: true
      issuerRef:
        name: <YOUR_TRUSTED_CA>
      dnsNames:
        - auditor.scalardl.example.com

この場合、cert-manager は信頼できる発行者を使用して秘密鍵と証明書ファイルを発行します。秘密鍵と証明書ファイルを手動でマウントする必要はありません。

cert-manager で自己署名 CA を使用して秘密鍵と証明書ファイルを管理する

次の構成を使用して、cert-manager で秘密鍵と自己署名証明書ファイルを管理できます。

注記

• cert-manager を使用する場合は、cert-manager をデプロイする必要があります。詳細については、cert-manager のドキュメントインストールを参照してください。
• デフォルトでは、Scalar Helm Chart は Scalar 製品の証明書要件を満たす Certificate リソースを作成します。デフォルトの証明書構成が推奨されますが、カスタム証明書構成を使用する場合は、Scalar 製品の証明書要件を満たす必要があります。詳細については、Scalar 製品の秘密鍵と証明書ファイルを作成する方法を参照してください。

auditor:
  tls:
    enabled: true
    certManager:
      enabled: true
      selfSigned:
        enabled: true
      dnsNames:
        - auditor.scalardl.example.com

この場合、Scalar Helm Charts と cert-manager が秘密鍵と自己署名証明書ファイルを発行します。秘密鍵と証明書ファイルを手動でマウントする必要はありません。

ScalarDL Ledger のルート CA 証明書を設定する

ScalarDL Ledger 側で TLS を有効にする場合は、ScalarDL Auditor からアクセスできるように、ScalarDL Ledger の前にある Envoy のルート CA 証明書ファイルを設定する必要があります。どのアプローチを取るべきかを判断するには、次の意思決定ツリーを参照してください。

Envoy のルート CA 証明書ファイルを手動で設定する必要がある場合は、次の構成を使用して設定できます。

auditor:
  tls:
    enabled: true
    caRootCertForLedgerSecret: "scalardl-auditor-tls-ca-for-ledger"

この場合、次のように山括弧内の内容を置き換えて、ルート CA 証明書ファイルを含むシークレットリソースを作成する必要があります。

kubectl create secret generic scalardl-auditor-tls-ca-for-ledger --from-file=ca.crt=/<PATH_TO_ROOT_CA_CERT_FILE_FOR_ENVOY_IN_FRONT_OF_SCALARDL_LEDGER>/scalardl-ledger -n <NAMESPACE>

TLS通信のカスタム権限を設定する

auditor.tls.overrideAuthority を使用して、TLS 通信のカスタム権限を設定できます。この値によって、実際に接続されているホストが変わることはありません。この値はテスト用ですが、DNS オーバーライドの代替としてテスト以外でも安全に使用できます。たとえば、auditor.tls.certChainSecret を使用して設定した証明書チェーンファイルで提示されるホスト名を指定できます。このチャートでは、startupProbe と livenessProbe にこの値を使用しています。

レプリカ構成 (環境に応じてオプション)

ScalarDL Auditor のレプリカ (ポッド) の数は、auditor.replicaCount を使用して指定できます。

auditor:
  replicaCount: 3

ロギング構成 (環境に応じてオプション)

ScalarDL Auditor のログレベルを変更したい場合は、auditor.scalarAuditorConfiguration.auditorLogLevel を使用できます。

auditor:
  scalarAuditorConfiguration:
    auditorLogLevel: INFO

汚染と許容の構成 (環境に応じてオプション)

Kubernetes のテイントと許容を使用してポッドのデプロイメントを制御したい場合は、auditor.tolerations を使用できます。

Kubernetes の許容と同じ構文を使用して、テイントと許容を構成できます。Kubernetes での許容設定の詳細については、Kubernetes の公式ドキュメント Taints and Tolerations を参照してください。

auditor:
  tolerations:
    - effect: NoSchedule
      key: scalar-labs.com/dedicated-node
      operator: Equal
      value: scalardl-auditor