Skip to content

Configuring Venafi Kubernetes Manifest tool

Choosing components

The Venafi Kubernetes Manifest utility generates a manifest with the configuration required to install Venafi components in a Kubernetes cluster.

You can add a component to the generated manifest by using the corresponding flag. The Venafi Kubernetes Manifest tool installs dependencies for any requested components by default.

The following example generates a manifest with cert-manager and Venafi Enhanced Issuer:

venctl components kubernetes manifest generate --venafi-enhanced-issuer

In this case, cert-manager is included because Venafi Enhanced Issuer depends on it.

To disable dependencies, use the --ignore-dependencies flag but be careful as this could lead to an broken installation if you haven't already set up required components in the correct namespace beforehand.

The generated manifest specifies everything about your installation, allowing you to inspect what is applied to the Kubernetes cluster later on.

Regions

The Venafi Kubernetes Manifest tool supports different regions for pulling images: "US" and "EU".

The default region is US but you can choose a region using the --region flag:

venctl components kubernetes manifest generate --region eu --cert-manager

Version pinning

Platform operators can specify exact versions of Venafi Kubernetes components charts if desired. If no version is specified, an installed component uses the default version specified when the Venafi Kubernetes Manifest binary was built.

If you upgrade to a newer version of the tool, the default versions it installs may change (as new versions of components are released).

# Pin the Venafi Enhanced Issuer to v0.8.0
venctl components kubernetes manifest generate --venafi-enhanced-issuer --venafi-enhanced-issuer-version v0.8.0

All default versions can be viewed with venctl components kubernetes manifest print-versions.

Air-gapped environments and custom registries

The Venafi Kubernetes Manifest utility supports pulling images and charts from self-hosted registries, which can be air-gapped if needed.

Both Helm chart repositories and container image registries can be replaced. Both can be done on a per-component or cluster-wide basis.

Protected and custom Helm repositories

To change the default Helm chart repository for all components use --custom-chart-repository.

To change the Helm chart repository for a specific component, use --<name>-custom-chart-repository.

The Venafi Kubernetes Manifest tool uses a URI scheme to work out how to pull charts. Setting a custom chart repository requires you to specify a scheme of either "https", "http" or "oci".

If you are using a protected OCI-based Helm registry, you can provide authentication credentials by providing a docker_config.json file with the --custom-chart-repository-config flag. For example:

venctl components kubernetes manifest generate \
  --cert-manager \
  --custom-chart-repository oci://my-registry.example.com/charts \
  --custom-chart-repository-config docker_config.json

For a HTTPS-based Helm registry you can specify the username and password using the --custom-chart-repository-username and custom-chart-repository-password (the following example uses a component-specific version of these commands - in this case Approver Policy), for example:

venctl components kubernetes manifest generate \
  --cert manager \
  --approver-policy-custom-chart-repository https://my-charts.example.com/ \
  --approver-policy-custom-chart-repository-username <username> \
  --approver-policy-custom-chart-repository-password <password>

Info

For more information on using the Venafi CLI tool venctl components kubernetes applyand venctl components kubernetes manifest generate command flags for protected repositories, see the Kubernetes Manifest tool commands.

Container image registries

To change the default container registry for pulling images for all components in-cluster, use --custom-image-registry.

To change the registry for a specific component, use --<name>-custom-image-registry.

For example:

venctl components kubernetes manifest generate \
  --custom-image-registry reg.example.com/venafi-images \
  --cert-manager \
  --venafi-enhanced-issuer-custom-image-registry reg2.example.net/vei

In this example, the Venafi Kubernetes Manifest tool pulls cert-manager images from reg.example.com/venafi-images/ (e.g. reg.example.com/venafi-images/cert-manager-controller, among others). It pulls Images for Venafi Enhanced Issuer from reg2.example.net/vei.

You must ensure that you have the appropriate image pull secrets configured in your cluster before you apply your generated manifest.

Custom values.yaml files

Your generated manifest has some Helm values set, such as updated image pull locations and best practices. The actual Helm charts you are installing may also have many other options available which you can configure through values.yaml files.

Each component can have its own values files added. These files are loaded when the manifest is applied to a cluster, and so the path to the file must be relative to the manifest.

The Venafi CLI tool venctl components kubernetes manifest generate command has several flags that allow to specify a file containing Helm values for different components:

  • --approver-policy-values-files
  • --approver-policy-enterprise-values-files
  • --aws-privateca-issuer-values-files
  • --cert-manager-values-files
  • --csi-driver-values-files
  • --firefly-values-files
  • --trust-manager-values-files
  • --venafi-kubernetes-agent-values-files
  • --venafi-connection-values-files
  • --venafi-enhanced-issuer-values-files

You can add custom values files by passing a comma-separated list of files in a flag like --<component-name>-values-files a.yaml,folder/b.yaml. For example:

# a.yaml
# Set the number of Trust Manager replicas to 2
replicaCount: 2

venctl components kubernetes manifest generate --approver-policy --trust-manager --trust-manager-values-files a.yaml

See the Related links section below for links to the custom Helm values reference pages.

Global tolerations

The --global-tolerations-file flag for the venctl components kubernetes manifest generate command points to a YAML file containing an array of Kubernetes corev1.Toleration objects. For more information, see the venctl components kubernetes manifest generate command reference documentation.

The Venafi CLI tool parses and validates tolerations using the same logic as Kubernetes. This means that it is impossible to specify an invalid toleration here.

See the following examples:

# global_tolerations.yaml

- key: node-role.kubernetes.io/infra
  operator: Exists
  effect: NoSchedule
- key: node-role.kubernetes.io/private
  operator: Exists
  effect: NoSchedule

venctl components kubernetes manifest generate --cert-manager --global-tolerations-file global_tolerations.yaml
...
releases:
- chart: venafi-charts/cert-manager
...
name: cert-manager
namespace: venafi
values:
- global:
    imagePullSecrets:
    - name: venafi-image-pull-secret
- extraArgs:
    - --controllers=*,-certificaterequests-approver
- tolerations:
    - key: node-role.kubernetes.io/infra
    operator: Exists
    effect: NoSchedule
    - key: node-role.kubernetes.io/private
    operator: Exists
    effect: NoSchedule
- webhook:
    tolerations:
    - key: node-role.kubernetes.io/infra
        operator: Exists
        effect: NoSchedule
    - key: node-role.kubernetes.io/private
        operator: Exists
        effect: NoSchedule
- cainjector:
    tolerations:
    - key: node-role.kubernetes.io/infra
        operator: Exists
        effect: NoSchedule
    - key: node-role.kubernetes.io/private
        operator: Exists
        effect: NoSchedule
- startupapicheck:
    tolerations:
    - key: node-role.kubernetes.io/infra
        operator: Exists
        effect: NoSchedule
    - key: node-role.kubernetes.io/private
        operator: Exists
        effect: NoSchedule
...

Global affinities

The --global-affinities-file for the venctl components kubernetes manifest generate command points to a YAML file containing an array of Kubernetes corev1.Affinity objects, which is validated in the same way that Kubernetes validates affinities in-cluster. For more information, see the venctl components kubernetes manifest generate command reference documentation, and the following example:

# global_affinities.yaml

nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
      - matchExpressions:
      - key: test.example.com/zone
        operator: In
        values:
          - antarctica-east1

venctl components kubernetes manifest generate --cert-manager --global-affinities-file global_affinities.yaml
...
name: cert-manager
namespace: venafi
values:
- global:
    imagePullSecrets:
    - name: venafi-image-pull-secret
- extraArgs:
    - --controllers=*,-certificaterequests-approver
- affinity:
    nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
            - key: test.example.com/zone
            operator: In
            values:
            - antarctica-east1
- webhook:
    affinity:
        nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
            - key: test.example.com/zone
                operator: In
                values:
                - antarctica-east1
- cainjector:
    affinity:
        nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
            - key: test.example.com/zone
                operator: In
                values:
                - antarctica-east1
- startupapicheck:
    affinity:
        nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
            - key: test.example.com/zone
                operator: In
                values:
                - antarctica-east1
...

Global topology spread constraints

The --global-topology-spread-constraints-file flag for the venctl components kubernetes manifest generate command allows you to configure global topology spread constraints which can be applied to all components for which topology spread constraints are configurable. For more information, see the venctl components kubernetes manifest generate command reference documentation.

The --global-topology-spread-constraints-file flag takes the path to a file containing an array of Kubernetes corev1 TopologySpreadConstraint resources using the same logic as Kubernetes.

The validated topology spread constraints are included in the generated manifest, and applied to components when the manifest is deployed.

See the following example:

# global_topology_spread_constraints.yaml

- maxSkew: 1
  topologyKey: kubernetes.io/hostname
  whenUnsatisfiable: ScheduleAnyway
  labelSelector:
    matchLabels:
      app.kubernetes.io/managed-by: Helm

venctl components kubernetes manifest generate --namespace venafi --global-topology-spread-constraints-file global_topology_spread_constraints.yaml --cert-manager
repositories:
- name: venafi-charts
url: registry.venafi.cloud/charts
oci: true
commonLabels:
venafi.com/manifest-generator: 'true'
releases:
- chart: venafi-charts/cert-manager
version: v1.14.4
...
- topologySpreadConstraints:
    - maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
        matchLabels:
        app.kubernetes.io/managed-by: Helm
- webhook:
    topologySpreadConstraints:
    - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
        matchLabels:
            app.kubernetes.io/managed-by: Helm
- cainjector:
    topologySpreadConstraints:
    - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
        matchLabels:
            app.kubernetes.io/managed-by: Helm
- startupapicheck:
    topologySpreadConstraints:
    - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
        matchLabels:
            app.kubernetes.io/managed-by: Helm
...

FIPS Images

Venafi provide FIPS-compliant builds of most enterprise Kubernetes components. If you run in an environment which requires FIPS compliance, you can request FIPS versions of components using the Venafi Kubernetes Manifest generator.

venctl components kubernetes manifest generate --cert-manager --approver-policy-enterprise --trust-manager --use-fips-images

Custom namespaces

By default all modules are installed to the venafi namespace. To change the target namespace, generate the manifest with the --namespace option:

venctl components kubernetes manifest generate --venafi-enhanced-issuer --namespace mynamespace

Custom image pull secret names

By default, the Venafi Kubernetes Manifest tool expects an image pull secret called venafi-image-pull-secret to be present in the install namespace.

If you want to use a custom name for that secret, or if you need to pass multiple secrets, do this when generating your manifest:

# Pass a single image pull secret to override the default
venctl components kubernetes manifest generate --image-pull-secret-names mysecret

# Pass multiple image pull secrets in a comma separated list - all secrets will be used
venctl components kubernetes manifest generate --image-pull-secret-names mysecret,someothersecret