Configure a custom values file for ScalarDL Auditor

This document explains how to create your custom values file for the ScalarDL Auditor chart. If you want to know the details of the parameters, please refer to the README of the ScalarDL Auditor chart.

Required configurations

Scalar Envoy configurations

You must set the Scalar Envoy configurations in the custom values file for ScalarDL Auditor. This is because client requests are sent to ScalarDL Auditor via Scalar Envoy as the load balancer of gRPC requests if you deploy ScalarDL Auditor on a Kubernetes environment.

Please refer to the document Configure a custom values file for Scalar Envoy for more details on the Scalar Envoy configurations.

envoy:
  configurationsForScalarEnvoy: 
    ...

auditor:
  configurationsForScalarDLAuditor: 
    ...

Image configurations

You must set auditor.image.repository. Be sure to specify the ScalarDL Auditor container image so that you can pull the image from the container repository.

auditor:
  image:
    repository: <SCALARDL_AUDITOR_CONTAINER_IMAGE>

For more details on the container repository for Scalar products, see How to get the container images of Scalar products.

Auditor/Database configurations

You must set auditor.auditorProperties. Please set your auditor.properties to this parameter. Please refer to the auditor.properties for more details on the configuration of ScalarDL Auditor.

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

Key/Certificate configurations

You must set a private key file to scalar.dl.auditor.private_key_path and a certificate file to scalar.dl.auditor.cert_path.

You must also mount the private key file and the certificate file on the ScalarDL Auditor pod.

For more details on how to mount the private key file and the certificate file, refer to Mount key and certificate files on a pod in ScalarDL Helm Charts.

Optional configurations

Resource configurations (Recommended in the production environment)

If you want to control pod resources using the requests and limits of Kubernetes, you can use auditor.resources.

Note that the resources for one pod of Scalar products are limited to 2vCPU / 4GB memory from the perspective of the commercial license. Also, when you get the pay-as-you-go containers provided from AWS Marketplace, you cannot run those containers with more than 2vCPU / 4GB memory configuration in the resources.limits. When you exceed this limitation, pods are automatically stopped.

You can configure them using the same syntax as the requests and limits of Kubernetes. So, please refer to the official document Resource Management for Pods and Containers for more details on the requests and limits of Kubernetes.

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

Secret configurations

If you want to use environment variables to set some properties (e.g., credentials) in the auditor.auditorProperties, you can use auditor.secretName to specify the Secret resource that includes some credentials.

For example, you can set credentials for a backend database (scalar.db.username and scalar.db.password) using environment variables, which makes your pods more secure.

Please refer to the document How to use Secret resources to pass the credentials as the environment variables into the properties file for more details on how to use a Secret resource.

auditor:
  secretName: "auditor-credentials-secret"

Affinity configurations (Recommended in the production environment)

If you want to control pod deployment using the affinity and anti-affinity of Kubernetes, you can use auditor.affinity.

You can configure them using the same syntax as the affinity of Kubernetes. So, please refer to the official document Assigning Pods to Nodes for more details on the affinity configuration of Kubernetes.

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 configurations (Recommended in the production environment)

If you want to monitor ScalarDL Auditor pods using kube-prometheus-stack, you can deploy a ConfigMap, a ServiceMonitor, and a PrometheusRule resource for kube-prometheus-stack using auditor.grafanaDashboard.enabled, auditor.serviceMonitor.enabled, and auditor.prometheusRule.enabled.

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

SecurityContext configurations (Default value is recommended)

If you want to set SecurityContext and PodSecurityContext for ScalarDL Auditor pods, you can use auditor.securityContext and auditor.podSecurityContext.

You can configure them using the same syntax as SecurityContext and PodSecurityContext of Kubernetes. So, please refer to the official document Configure a Security Context for a Pod or Container for more details on the SecurityContext and PodSecurityContext configurations of Kubernetes.

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

TLS configurations (optional based on your environment)

You can enable TLS in:

• The communications between the ScalarDL Auditor and clients.
• The communications between the ScalarDL Ledger and ScalarDL Auditor.

In addition, you have several options for certificate management. For more details, see TLS configurations for Envoy.

You should consider which method you use based on your security requirements. For guidance and related documentation for each method, refer to the following decision tree:

Enable TLS

You can enable TLS in all ScalarDL Auditor connections by using the following configurations:

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

Use your private key and certificate files

You can set your private key and certificate files by using the following configurations:

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

In this case, you have to create secret resources that include private key and certificate files for ScalarDL Ledger and ScalarDL Auditor as follows, replacing the contents in the angle brackets as described:

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>

For more details on how to prepare private key and certificate files, see How to create private key and certificate files for Scalar products.

Use a trusted CA with cert-manager to manage your private key and certificate files

You can manage your private key and certificate files with cert-manager by using the following configurations, replacing the content in the angle brackets as described:

note

• If you want to use cert-manager, you must deploy cert-manager and prepare the Issuers resource. For details, see the cert-manager documentation, Installation and Issuer Configuration.
• By default, Scalar Helm Chart creates a Certificate resource that satisfies the certificate requirements of Scalar products. The default certificate configuration is recommended, but if you use a custom certificate configuration, you must satisfy the certificate requirements of Scalar products. For details, see How to create private key and certificate files for Scalar products.

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

In this case, cert-manager issues your private key and certificate files by using your trusted issuer. You don't need to mount private key and certificate files manually.

Use a self-signed CA with cert-manager to manage your private key and certificate files

You can manage your private key and self-signed certificate files with cert-manager by using the following configurations:

note

• If you want to use cert-manager, you must deploy cert-manager. For details, see the cert-manager documentation, Installation.
• By default, Scalar Helm Chart creates a Certificate resource that satisfies the certificate requirements of Scalar products. The default certificate configuration is recommended, but if you use a custom certificate configuration, you must satisfy the certificate requirements of Scalar products. For details, see How to create private key and certificate files for Scalar products.

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

In this case, Scalar Helm Charts and cert-manager issue your private key and self-signed certificate files. You don't need to mount private key and certificate files manually.

Set a root CA certificate for ScalarDL Ledger

If you enable TLS on the ScalarDL Ledger side, you must set a root CA certificate file for Envoy in front of ScalarDL Ledger to access it from ScalarDL Auditor. To determine which approach you should take, refer to the following decision tree:

If you need to set the root CA certificate file of Envoy manually, you can set it by using the following configurations:

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

In this case, you have to create secret resources that include root CA certificate files as follows, replacing the contents in the angle brackets as described:

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>

Set custom authority for TLS communications

You can set the custom authority for TLS communications by using auditor.tls.overrideAuthority. This value doesn't change what host is actually connected. This value is intended for testing but may safely be used outside of tests as an alternative to DNS overrides. For example, you can specify the hostname presented in the certificate chain file that you set by using auditor.tls.certChainSecret. This chart uses this value for startupProbe and livenessProbe.

Set a root CA certificate for Prometheus Operator

If you set auditor.serviceMonitor.enabled=true and auditor.tls.enabled=true (in other words, if you monitor ScalarDL Auditor with TLS configuration by using Prometheus Operator), you must set the secret name to auditor.tls.caRootCertSecretForServiceMonitor.

auditor:
  tls:
    enabled: true
    caRootCertSecretForServiceMonitor: "scalardl-auditor-tls-ca-for-prometheus"

In this case, you have to create secret resources that include a root CA certificate for ScalarDL Auditor in the same namespace as Prometheus as follows:

kubectl create secret generic scalardl-auditor-tls-ca-for-prometheus --from-file=ca.crt=/path/to/your/ca/certificate/file -n <NAMESPACE_SAME_AS_PROMETHEUS>

Replica configurations (Optional based on your environment)

You can specify the number of replicas (pods) of ScalarDL Auditor using auditor.replicaCount.

auditor:
  replicaCount: 3

Logging configurations (Optional based on your environment)

If you want to change the log level of ScalarDL Auditor, you can use auditor.scalarAuditorConfiguration.auditorLogLevel.

auditor:
  scalarAuditorConfiguration:
    auditorLogLevel: INFO

Taint and toleration configurations (Optional based on your environment)

If you want to control pod deployment by using the taints and tolerations in Kubernetes, you can use auditor.tolerations.

You can configure taints and tolerations by using the same syntax as the tolerations in Kubernetes. For details on configuring tolerations in Kubernetes, see the official Kubernetes documentation Taints and Tolerations.

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