Managing Certificates for TLS

IT Asset Management (Cloud)
On a regular interval (by default, once every 24 hours, or the setting you provide through the ‑‑inventory‑interval flag), the Lightweight Kubernetes Inventory Agent uploads its collected inventory to a single inventory beacon, for which the URL is specified in the --beacon flag or alternative environment variables (for details, see Options for the Lightweight Kubernetes Agent). If this URL is not specified, the Lightweight Kubernetes Inventory Agent immediately exits with an error printed to stdout, and viewable with the following command (replacing the placeholder with the appropriate pod name):
kubectl logs -n flexera lwkPod
As always, the complete URL must include the protocol (HTTP or HTTPS). If your inventory beacon is configured for HTTPS communication, secure communications are protected with Transport Layer Security (TLS).
Tip: Currently the Lightweight Kubernetes Inventory Agent supports only standard (single-sided) TLS, and does not support mutual TLS.
TLS requires that the inventory beacon presents a server certificate that can be validated by the client (in this case, the Lightweight Kubernetes Inventory Agent) against a certificate chain culminating in a root certificate for the issuing Certificate Authority (CA). This means that the CA root certificate (and any intermediate certificates, as applicable) must be present and accessible on the client device. Otherwise, the Lightweight Kubernetes Inventory Agent will refuse the connection to the inventory beacon because of an untrusted certificate (but see also ‑‑ibm-licensing-tls-verify inOptions for the Lightweight Kubernetes Agent).

To validate the server certificate presented by the inventory beacon, the Lightweight Kubernetes Inventory Agent checks for a file mounted into the container at the path /beacon.pem. If this is found, the certificates it contains are appended to the trust bundle for the Lightweight Kubernetes Inventory Agent.

Certificate bundle constraints

  • The CA certificate bundle must use the PEM encoding.
  • The server certificate used by the inventory beacon must use the Subject Alternative Name extension. (This is because the Lightweight Kubernetes Inventory Agent is implemented in Go [version 1.16 or later]. After Go version 1.5, clients no longer support server identification using the Common Name attribute of the certificate.) If your current certificate for the relevant inventory beacon does not currently include the Subject Alternative Name, you need to generate a new CSR, with the Common Name attribute the same as in the current certificate, and reissue the certificate.

To configure the Lightweight Kubernetes Inventory Agent for a custom CA certificate bundle:

  1. If necessary, create a new Certificate Signing Request (CSR) for a CA to supply you with a new certificate that includes the Subject Alternative Name.
    For a reminder about how to prepare a CSR, see the online help under FlexNet Manager Suite Help > Inventory Beacons > Local Web Server Page > Configuring Mutual TLS at step 7, remembering to keep the same Common name as in the current certificate, and to add the Subject Alternative Name (ignore the fact that the help page is about mutual TLS, since the process of preparing a CSR is the same).
  2. If necessary, when a replacement certificate is received, load it into the inventory beacon.
    For a process reminder, see steps 8 and 10 in the same help topic.
  3. Take a copy of the CA root certificate from the inventory beacon, convert it to the .pem format, and save as ca‑certificates.pem.
    One method is to use the openssl toolkit, available through https://www.openssl.org/source/, on a convenient Windows device where you have openssl and a copy of the .pfx file you are deploying for Windows devices.
    1. To export the certificate (including the necessary public key) in a .pemfile: 
      openssl pkcs12 -in filename.pfx -clcerts -nokeys -out ca‑certificates.pem
    2. Open the resulting certificate file in your preferred flat text editor (such as Notepad), delete all preliminary lines of text before -----BEGIN CERTIFICATE-----, and save the amended file.
    3. If the certificate conversion has been completed on a different computer (such as, perhaps, a Windows-based inventory beacon), copy the finished .pem file to your working Linux-based computer.
  4. Add the CA certificate bundle to the Kubernetes ConfigMap (from your Linux-based computer): 
    kubectl create configmap custom-certs -n flexera --from-file=ca-certificates.pem
  5. In your preferred flat text editor, edit the deployment.yaml file to identify your configMap and define the appropriate storage.
    For example, if your configMap is named custom-certs (in the flexera namespace), you can name it as a volume beacon-ca-certificate in the pod section of your deployment.yaml file for Lightweight Kubernetes Inventory Agent:
    apiVersion: apps/v1
kind: Deployment
...
spec:
  template:
    spec:
      volumes:
        - name: beacon-ca-certificate
          configMap:
            name: custom-certs
      containers:
        - name: agent
          volumeMounts:
            - name: beacon-ca-certificate
              mountPath: /beacon.pem
              subPath: ca-certificate.pem
              readOnly: true
    Tip: The names of the configMap and the volume are not significant, and you may customize the names to suit your environment. However, the mountPath element of the volumeMount must be set to /beacon.pem.
Now, with your deployment.yaml file customized for the CA certificate bundle, you can resume your installation process, whether it is Scripted Installation or Manual Installation.

IT Asset Management (Cloud)

Current