Values File Settings for CA Connector Client Containers Under Kubernetes

When the CA ConnectorClosed The Keyfactor CA Connector is installed in the customer environment to provide a connection between a CA and Keyfactor Command when a direct connection is not possible. It is supported on both Windows and Linux and has versions for Microsoft (Windows only) or EJBCA CAs. Client is installed in a containerized implementation, there are a number of settings that can be configured in the values file to pass to the helm chart to provide customization. These are provided in the following table.

Table 1176: CA Connector Client Containerized Installation Values File Settings

Name

Description

 Example Default
connector
caConfigCacheExpirationMinutes

The number of minutes that the CA configuration will be cached before being cleared.

   10
connector
env
Other environment variables that should be included.    
connector
logLevel

The container logging level output. Supported values are:

  • OFF

    No logging

  • FATAL

    Log severe errors that cause early termination

  • ERROR

    Log severe errors and other runtime errors or unexpected conditions that may not cause early termination

  • WARN

    Log errors and use of deprecated APIs, poor use of APIs, almost errors, and other runtime situations that are undesirable or unexpected but not necessarily wrong

  • INFO

    Log all of the above plus runtime events (startup/shutdown)

  • DEBUG

    Log all of the above plus detailed information on the flow through the system

  • TRACE

    Maximum log information—this option can generate VERY large log files

   Info
connector
name
The name the CA connector uses to register itself in Keyfactor Command.   By default, the Kubernetes pod name is used if this value is not specified.
connector
oauthServer
audience
The audience value for tokens issued from the OAuth identity provider.    
connector
oauthServer
scope
One or more scopes that should be included in token requests delivered to the OAuth identity provider when making a token request. Multiple scopes should be separated by spaces.    
connector
oauthServer
secretClientIdKey
The key within the Kubernetes secret named by secretName referencing the ID for the client application created in the OAuth identity provider to allow the CA connector to make requests to Keyfactor Command.   client-id
connector
oauthServer
secretClientSecretKey
The key within the Kubernetes secret named by secretName referencing the secret value for the client application created in the OAuth identity provider to allow the CA connector to make requests to Keyfactor Command.   client-secret
connector
oauthServer
SecretName
The name of the Kubernetes secret containing the secret values for the client application created in the OAuth identity provider to allow the CA connector to make requests to Keyfactor Command.   client-credentials
connector
oauthServer
tokenUrl
The URL of the token endpoint for your OAuth identity provider.    
connector
serverUrl
The URL to the CA connector application on the Keyfactor Command server. SSL is required to connect to the Keyfactor Command server. https://kyf101.keyfactorpki.com/KeyfactorCAConnectors  
connector
signalR
skipNegotiation

When set to true, tells the SignalR client to skip the negotiation step during the connection.

   false
connector
signalR
transportTypes

Specifies the transport types that SignalR should use to establish a connection.

   “WebSockets, LongPolling”
containerSecurityContext
allowPrivilegeEscalation

Specifies whether a process in a container can gain more privileges than its parent process. If set to true, processes in the container can escalate their privileges, potentially allowing them to gain additional system capabilities. If set to false, privilege escalation is prevented, which can improve security by limiting the container's ability to perform actions that require higher privileges than the container's default security context allows.

   false
resources
limits
memory

The maximum memory the container may use.

   2G
fullnameOverride

Provide the deployment with a completely custom name, overriding both the default name of the Helm release defined in the chart.yaml file and the name of the Helm deployment provided in the Helm install command.

    
image
pullPolicy

The pullPolicy defines when the container image should be pulled from the Keyfactor artifactory. It can be set to Always (pull the image every time the container starts), IfNotPresent (pull only if the image is not already present locally), or Never (never pull the image, only use the locally available version). This helps control image pulling behavior and optimize deployments.

   IfNotPresent
imagePullSecrets
- name

The Kubernetes secret name given to the credentials used to authenticate to the Keyfactor artifactory to retrieve the image.

    
image
repository

The CA Connector Client image to retrieve from the Keyfactor artifactory, including the artifactory path.

   repo.keyfactor.com/images/command/ca-connector
image
tag

The tag specifies the version or variant of the container image to be used. For the CA Connector Client, the default value is set to the chart's appVersion, ensuring that the container image corresponds to the version of the application defined in the Helm chart. This provides consistency between the chart version and the deployed application version, ensuring predictable deployments.

Specify a version number to deploy a release of the CA Connector Client other than that specified in the Helm chart.

   The chart appVersion
initContainers

For more information on this data structure, see:

https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

   
metadata
annotations

Annotations are key-value pairs used to store arbitrary, non-identifying metadata on Kubernetes resources. They are typically used for integration with external tools, storing build information, or documenting deployment details. Annotations do not affect the resource’s behavior and are not used for selection.

    
metadata
labels

Labels are key-value pairs used to categorize and identify Kubernetes resources for easy selection and management. They are often used for grouping resources by application, environment, or version, enabling efficient querying and filtering. Labels are essential for resource selection and grouping in Kubernetes operations.

    
nameOverride

Override the default name of the Helm release defined in the chart.yaml file. For the CA Connector Client this value is:

ca-connector

This setting does not override the name of the Helm deployment provided in the Helm install command. For example, if you set this value to my-ca-connector and execute the following Helm install command:

sudo helm install ca-connector-one --namespace keyfactor-connector --values values.yaml oci://repo.keyfactor.com/charts/command/ca-connector --version 1.0.0

The resulting deployment name would be:

ca-connector-one-my-ca-connector
    
podSecurityContext
runAsNonRoot

The runAsNonRoot parameter specifies whether the pod's containers should be run as a non-root user. When set to true, the containers must run as a user other than root, improving security by adhering to the principle of least privilege. If set to false (or not specified), containers may run as the root user, which could increase security risks.

   true
podSecurityContext
runAsUser

The runAsUser parameter specifies the user ID (UID) that the containers in the pod should run as. By setting this value, you ensure that the containers run with the specified user privileges, rather than the default root user. This enhances security by limiting the container’s access to system resources and following the principle of least privilege. This value is used if runAsNonRoot is true.

   1000
resources
limits
cpu

The maximum CPU the container may use.

   500m
serviceAccount
annotations

ServiceAccount annotations are key-value pairs used to attach non-identifying metadata to the service account resource. These annotations are typically used for integration with external tools, documenting configurations, or adding extra information relevant to the service account's usage. Like other annotations, they don't affect the resource's functionality and aren't used for selection.

    
serviceAccount
create

Create a new service account (true) or not (false).

For more information on service accounts, see:

https://kubernetes.io/docs/concepts/security/service-accounts/

  true
serviceAccount
name

The name of an existing service account to use, or the name to give to a service account to be created.

   If create is true but the name is not provided, the default name will be used.
sidecarContainers

Additional containers that run alongside the main application container within a pod are known as sidecarContainers. These containers typically provide supporting functionality, such as logging, monitoring, or proxying, without modifying the primary application's behavior. These sidecarContainers share the same network namespace and storage volumes as the main container, enabling close integration.

For more information on this data structure, see:

https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/

No sidecarContainers are included by default.

    
topologySpreadConstraints

The topologySpreadConstraints parameter defines rules for distributing pods across nodes to ensure high availability and fault tolerance. It allows you to control how pods are spread across different failure domains, such as availability zones or regions, to prevent resource contention and ensure that the application remains functional even if one domain fails.

For more information on this data structure, see:

https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/

No topology spread constraints are included by default.

    
volumeMounts
- name

An array of volume mounts. This parameter specifies the name of the volume mount. The value should match the value set by volumes > -name.

The example values file (see Kubernetes with Helm) includes a volume mount for the config map ca-roots to mount trusted CA certificates.

For more information on this data structure, see:

https://kubernetes.io/docs/concepts/storage/volumes/
root-cas  
volumeMounts
mountPath

The mountPath specifies the path within the container where a volume should be mounted. It can be a directory or a specific file, depending on the mount configuration, allowing the container to access the contents of the volume at that location.

 /etc /ssl /certs /ca-certificates .crt  
volumeMounts
subPath

The subPath specifies a subdirectory or file within the volume to mount at the mountPath. This allows you to mount only a specific part of the volume, rather than the entire volume, giving more fine-grained control over which data is exposed to the container.

 ca-certificates.crt  
volumes
- name

An array of volumes. This parameter specifies the name of the volume. The value should match the value set by volumeMounts > -name.

The example values file (see Kubernetes with Helm) includes a volume mount for the config map ca-roots to mount trusted CA certificates.

 root-cas  
volumes
configMap
items
- key

The Kubernetes ConfigMap key name given to the referenced value in the ConfigMap.

 ca-certificates.crt  
volumes
configMap
items
path

The name of the mounted file, referenced by the Kubernetes ConfigMap, as it will appear in the volume.

In the example values file, the data from the ConfigMap key ca-certificates.crt will be written to a file called ca-certificates.crt in the container volume.

 ca-certificates.crt  
volumes
configMap
name

The name given to the Kubernetes ConfigMap for the volume.

 ca-roots