preflight

README

Venafi Kubernetes 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 tests.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.