Issuer Authentication Methods with TLS Protect Datacenter¶

In order for Issuer to operate with TLS Protect Datacenter, it must be represented as a user identity within the TLS Protect Datacenter system. This identity can then authenticate using various methods, such as a JSON Web Token (JWT) or a username and password. Below, you will find more details about the available authentication methods and how to configure them.

Configuring Issuer to use OIDC authentication with TLS Protect Datacenter¶

Issuer can be configured to use OIDC authentication with a JSON Web Token (JWT) signed by the Kubernetes platform and verified by TLS Protect Datacenter. This method leverages short-lived, dynamic credentials that are issued on demand and are not stored on the Kubernetes platform.

Although this is a more complex setup, it is the recommended authentication method, as it aligns with modern security best practices.

To learn how to configure Issuer to use OIDC authentication with JWT, follow the instructions in Authenticating to TLS Protect Datacenter

Configuring Issuer to use username and password authentication with TLS Protect Datacenter¶

There are cases where OIDC authentication is not applicable, and an alternative authentication method must be used. One example is when Issuer is not deployed on a Kubernetes platform. In such scenarios, the username and password approach can be used instead.

There are two options for storing the credentials: as a Kubernetes Secret or as a file on the filesystem.

Using credentials stored as a Kubernetes Secret¶

The following is an example of a values file that can be used when deploying Issuer with Helm. In this scenario, a Connection resource will be created after deployment and configured to use username and password authentication to TLS Protect Datacenter. Before deploying Issuer, you should create a Kubernetes Secret containing the credentials:

kubectl create secret generic firefly-credentials \
  --namespace=venafi \
  --from-literal=username='firefly' \
  --from-literal=password='topsecret'

Below is an example of a values file showing a sample configuration where the username and password will be loaded from a Kubernetes Secret:

acceptTerms: true
deployment:
  extraVolumes: # (1)!
  - name: ca-bundle-cert
    secret:
      secretName: ca-bundle-cert
  extraVolumeMounts: # (2)!
  - mountPath: /etc/ssl/certs/
    name: ca-bundle-cert
  config:
    bootstrap:
      tpp:
        enabled: true
        csr:
          instanceNaming: Instance1 Location1 # (3)!
        configurationDN: firefly\\security-config # (4)!
        connection:
          create: true # (5)!
          name: tpp-connection
          url: https://tpp.example.com/ # (6)!
          usernamePassword: # (7)!
            enabled: true
            name: firefly-credentials # (8)!
    controller:
      enabled: true # (9)!
      certManager:
        caRootChainPopulation: false # (10)! 
        checkApproval: true # (11)!

1. Omit this section if TLS Protect Datacenter is using a publicly trusted TLS certificate for its API.
2. Omit this section if TLS Protect Datacenter is using a publicly trusted TLS certificate for its API.
3. The naming pattern for the Issuer instances.
4. The name of the Issuer security configuration.
5. If set to true, a Connection resource will be created with the specified name and authentication method.
6. The TLS Protect Datacenter URL.
7. The authentication method.
8. You must store the credentials in a Secret with the name specified here, within the same namespace as Issuer, using the following keys: username and password.
9. Set to false if you don't want Issuer to act as a Kubernetes Controller and process cert-manager Certificate resources.
10. Set to true if you want to automatically populate the status.ca field with the CA information.
11. Set to false if you want Issuer to process CertificateRequest resources without waiting for approval.

To install Issuer using Helm, run the following command:

helm install prod oci://registry.venafi.cloud/public/venafi-images/helm/firefly \
    --namespace venafi \
    --values firefly.values.yaml \
    --version v1.8.1

Using credentials stored as a file¶

The following is an example of a bootstrap configuration file that can be used when Issuer is run in non-Kubernetes environments, such as a standalone application on a Linux machine. In this scenario, a Connection resource will not be created, as the credentials will be loaded from a YAML file stored alongside Issuer.

Before running Issuer, you should create a YAML file containing the credentials:

(umask 377 && cat > firefly-credentials.yaml << EOF
username: firefly
password: topsecret
EOF
)

Below is an example bootstrap configuration file that can be passed to Issuer to read the credentials from a YAML file named firefly-credentials.yaml.

bootstrap:
  tpp:
    configurationDN: firefly\\security-config
    connection:
      inline:
        url: https://tpp.example.com/
        accessToken:
        - file:
            path: firefly-credentials.yaml
            fields: ["username", "password"]
        - tppOAuth:
            authInputType: UsernamePassword
            clientId: firefly
    csr:
      instanceNaming: Instance1 Location1
server:
  rest:
    port: 8281
    tls:
      dnsNames:
      - rest.firefly.local

To start Issuer, run:

ACCEPT_TERMS=Y ./firefly-pkcs11 run --config bootstrap.yaml