Discovery Agent

"The agent" manages your machine identities across Cloud Native Kubernetes and OpenShift environments and builds a detailed view of the enterprise security posture.

Installation

Please review the documentation for the agent.

Detailed installation instructions are available for a variety of methods.

Local Execution

To build and run a version from master:

go run main.go agent --agent-config-file ./path/to/agent/config/file.yaml -p 0h1m0s

You can configure the agent to perform one data gathering loop and output the data to a local file:

go run . agent \
   --agent-config-file examples/one-shot-secret.yaml \
   --one-shot \
   --output-path output.json

Some examples of agent configuration files:

• ./agent.yaml.
• ./examples/one-shot-secret.yaml.
• ./examples/cert-manager-agent.yaml.

You might also want to run a local echo server to monitor requests sent by the agent:

go run main.go echo

Metrics

The agent exposes its metrics through a Prometheus server, on port 8081.

The Prometheus server is disabled by default but can be enabled by passing the --enable-metrics flag to the agent binary.

If you deploy the agent using the venafi-kubernetes-agent Helm chart, the metrics server will be enabled by default, on port 8081.

If you use the Prometheus Operator, you can use --set metrics.podmonitor.enabled=true to deploy a PodMonitor resource, which will add the venafi-kubernetes-agent metrics to your Prometheus server.

The following metrics are collected:

• Go collector: via the default registry in Prometheus client_golang.
• Process collector: via the default registry in Prometheus client_golang.
• Agent metrics: data_readings_upload_size: Data readings upload size (in bytes) sent by the in-cluster agent.

End to end testing

An end to end test script is available in the ./hack/e2e/test.sh directory. It is configured to run in CI in the e2e.yaml GitHub Actions workflow. To run the script you will need to add the test-e2e label to the PR. The script creates a cluster in GKE and cleanups after itself unless the keep-e2e-cluster label is set on the PR. Adding that label will leave the cluster running for further debugging but it will incur costs so manually delete the cluster when done. Add keep-e2e-cluster before test-e2e, because test-e2e starts the run immediately and the labels are read as they were at that moment.