TLS Protect for Kubernetes
Log inCreate account
Important Announcement!

This deprecated version of TLS Protect for Kubernetes, originally known as Jetstack Secure, will be PERMANENTLY SHUTDOWN on May 19, 2025. If you're still using this version, please work with your CyberArk/Venafi account team to transition to the current version of TLS Protect for Kubernetes.

isolated-issuer Bootstrapper Configuration

Bootstrappers handle retrieving CA certificates to use for issuing other certificates.

Bootstrapping can be configured via either:

  • Local files,
  • cert-manager,
  • Venafi, or
  • HashiCorp Vault

Local

Local bootstrapping involves reading files on disk corresponding to the certificate and private key to use.

Local has a single option for configuring file path locations to the intermediate CA certificate private key pair.

bootstrap:
  local:
    # file path location to the PEM encoded intermediate private key
    privateKeyFile: key.pem


    # file path location to the PEM encoded intermediate CA certificate
    certificateFile: crt.pem
Copy to clipboard

Remote

CSR Configuration

All remote bootstrap options require a certificate request to be configured, which is used to describe the contents of the certificate request to be presented to the remote bootstrap provider.

bootstrap:
  remote:
    # Configuration for the CSR sent to remote bootstrap component
    csr:
      # [Go duration string](https://golang.org/pkg/time/#ParseDuration) denotes
      # the requested validity duration of the intermediate CA certificate.
      duration: 48h


      # The commonName requested for the intermediate CA certificate.
      commonName: isolated-issuer-intermediate


      # Configuration detailing the private key component
      privateKey:
        encoding: PKCS8
        algorithm: RSA
        size: 2048


      subject:
        # Organizations to be used on the CA certificate.
        organizations:
        - jetstack.io
        - example.com
        # Countries to be used on the CA certificate.
        countries:
        - UK
        - US
        # Organizational Units to be used on the CA certificate.
        organizationalUnits:
        - product
        - security
        # Cities to be used on the Certificate.
        localities:
        - London
        - New York
        # State/Provinces to be used on the CA certificate.
        provinces:
        - City of London
        - New York
        # Street addresses to be used on the CA certificate.
        streetAddresses:
        - Buckingham Palace, Westminster
        -  405 E 42nd St, New York
        # Postal codes to be used on the CA certificate.
        postalCodes:
        - SW1A 1AA
        - NY 10017
        # Serial number to be used on the CA certificate.
        serialNumber: "1234"
Copy to clipboard

Venafi

Below is the Venafi configuration for the remote bootstrap. A certificate request must also be defined.

bootstrap:
  remote:
    csr:
    ...
    venafi:
      # The target Venafi zone
      zone: TLS/SSL\Certificates\isolated-issuer
      tpp:
        # Venafi TPP must define either a username and password, or access token
        url: https://example.env.cloudshare.com/vedsdk
        username: user-1
        password: pass123
        accessToken: abc1234
Copy to clipboard

Venafi Policy Configuration

In the above configuration zone refers to a particular policy folder that exists on the Venafi platform, which means that the intermediate CA certificate requested by isolated-issuer will have a particular Venafi policy applied to it.

A certificate issued by Venafi inherits certain extensions, such as key usage and basic constraints from the CA template associated with the policy.

You should ensure that the CA template specifies that the subject of the certificate is a CA and key usages include Digital Signature, Key Encipherment, Certificate Sign.

You should also ensure that the policy allows for creation of User Provided CSRs.

cert-manager

Below is the cert-manager configuration for the remote bootstrap. A certificate request must also be defined.

bootstrap:
  remote:
    csr:
    ...
    cert-manager:
      # The cert-manager issuer resource name
      issuerName: isolated-issuer-int
      # The cert-mamager issuer resource kind (Issuer, ClusterIssuer)
      issuerKind: Issuer
      # The cert-mamager issuer resource group
      issuerGroup: cert-manager.io
      # The namespace where the certificate request will be created
      namespace: cert-manager
Copy to clipboard

Vault

Vault can issue intermediate certificates through the PKI secrets engine.

This requires that a root certificate has already been issued in Vault and that you know the path to this root.

For example if starting fresh using the Vault CLI:

export ROOT_PATH="myroot"


# 1. Create the path in Vault
vault secrets enable -path=$ROOT_PATH pki


# 2. Set the max duration of issued certs under this path
# (this will likely be longer for a root)
vault secrets tune -max-lease-ttl=87600h $ROOT_PATH


# 3. Issue the root certificate, storing the output in a JSON file
vault write -format=json $ROOT_PATH/root/generate/internal \
	common_name="isolated.example.com Root" \
	ttl=87600h > root.json


# 4. Pull out the root cert and store it in root.pem
jq ".data.certificate" -r < root.json > root.pem
Copy to clipboard

This guide is useful for getting to grips with PKI in Vault.

Aside from configuring the bootstrap, you'll also need to configure Vault connection URL and authentication details.

The following command will run an ephemeral local development Vault server, useful for testing:

vault server -dev -dev-root-token-id="abc"
Copy to clipboard

Finally, configure isolated-issuer to bootstrap using Vault:

bootstrap:
  remote:
    csr:
      ...
    vault:
      rootPath: myroot
      instance:
        url: http://127.0.0.1:8200
        apiToken: "abc"
        # namespace: "mynamespace"  # optional, set the Vault namespace
Copy to clipboard

Vault Permissions

Vault bootstrapping requires use of the following endpoint for the configured rootPath:

  • POST rootPath/root/sign-intermediate: Generating a new intermediate

See Vault Permissions for a complete guide to creating an isolated-issuer policy in Vault and then generating tokens to pass to isolated-issuer.

On this page