Agent configuration

The agent aims to be flexible in the resources it can monitor and transfer data for, allowing for configuration of different resource kinds. We aim to ensure that no sensitive information contained within those resources is unnecessarily uploaded to the platform. Please note, the resource requirements for operating the agent within a Kubernetes cluster will increase or decreased based on the number of resources within the cluster.

Certificate Identification

The agent extracts certificate information from the following resources:

• Certificate - A custom resource provided via a cert-manager installation that represents a single X.509 certificate.
• CertificateRequest - Another custom resource provided from a cert-manager installation. It represents a request to obtain an X.509 certificate from an Issuer. This resource is included for scenarios where integrations with cert-manager, such as istio-csr opt to store certificate data purely in CertificateRequest resources.
• Secret - The native Kubernetes Secret resource is the kind where cert-manager typically stores X.509 certificates. These are usually denoted by their type field (kubernetes.io/tls). However, the agent will also check secrets for the presence of certificates generally, where the tls.crt and tls.key data fields are present. This allows TLS Protect for Kubernetes to also monitor your unmanaged certificates.

By default the agent also collects more information about pods and pod controller resources, this is to identify where the certificate resources above are being used and other metadata for the platform.

Refer to the configuration section for how to filter the resources down if necessary.

Ingress Identification

The agent identifies entry points to your workloads from the following resources:

• Ingress - The native Kubernetes Ingress resource describes named routes to your Kubernetes services including the X.509 certificates they use to secure communication. TLS Protect for Kubernetes will provide information on the security of these routes based on the certificates they use.
• Route - The RedHat OpenShift alternative to Ingress resources. These work in a similar fashion to native ingresses in that they specify routes and the X.509 certificates they use. These will display within TLS Protect for Kubernetes with a custom icon to indicate they are OpenShift entrypoints.

Issuer Identification

The agent by default supports all native cert-manager issuers, as well as several external issuers:

• Google CAS
• AWS Private CA

Because external cert-manager issuers provide their own custom resource definitions, support for these need to be added to the platform individually. If you would like to see an external issuer supported in TLS Protect for Kubernetes please contact support.

Configuration

The agent is configured via a single YAML file that describes the resources it is allowed to monitor. When you add your cluster via the platform's web interface it will already include all the recommended resources to watch. If you want to exclude any of these it's as easy as removing those lines of configuration.

This configuration is important for handling different Kubernetes distributions. For example, the `Route` resource is the alternative to the Ingress resource within a RedHat OpenShift cluster.

Note: removing monitoring of certain resources may prevent you from using the full suite of features available in TLS Protect for Kubernetes.

An example configuration file may look like this:

server: "https://platform.jetstack.io"
organization_id: "my-organization"
cluster_id: "my_cluster"
data-gatherers:
  # basic usage

  - kind: "k8s-dynamic"
    name: "k8s/pods"
    config:
    resource-type:
    resource: pods
    version: v1

  # CRD usage

  - kind: "k8s-dynamic"
    name: "k8s/certificates.v1alpha2.cert-manager.io"
    config:
    resource-type:
    group: cert-manager.io
    version: v1alpha2
    resource: certificates

Each element in the data-gatherers list provides some additional configuration values:

• config.kubeconfig - Allows you to configure monitoring resources in an external cluster, the agent does not have to monitor resources purely in the cluster that it runs in. It can also be ran outside of clusters and use kubeconfig files for authentication.
• include-namespaces & exclude-namespaces - These allow you to filter the namespaces that the agent will monitor. By default, the agent will watch resources in all namespaces within the cluster.

Below are some examples of using these values:

data-gatherers:
  # include only the 'prod' namespace from another cluster

  - kind: "k8s-dynamic"
    name: "k8s/pods"
    config:
    kubeconfig: other_kube_config_path
    resource-type:
    resource: pods
    version: v1
    include-namespaces:
      - prod

  # exclude the kube-system namespace

  - kind: "k8s-dynamic"
    name: "k8s/pods"
    config:
    resource-type:
    resource: pods
    version: v1
    exclude-namespaces:
      - kube-system
        ```
```