[VC-43403] Disable events when not in cluster and only require installNamespace when using venafi-connection mode

[wallrj-cyberark]

It should be possible to run the agent outside a cluster, reading data from an input file and publishing to Jetstack or TLSPK, without having to supply any Kubernetes related configuration.

--install-namespace or POD_NAMESPACE is only required when using venafi-connection mode, because that client needs to know where to find the agent service account which it uses to impersonate the venafi-connection service account (I think).

So if the necessary POD_ environment variables are missing, the event recorder is now disabled.
And specifying an install namespace (by --install-namespace or by POD_NAMESPACE) are now optional, unless venafi-connection mode is used.

[wallrj-cyberark]

$ go test ./cmd/...  -v -count 1
=== RUN   TestAgentRunOneShot
    agent_test.go:32: Running child process
    agent_test.go:50: STDOUT
        I0821 16:50:33.617894  135769 run.go:58] "Starting" logger="Run" version="development" commit=""
        I0821 16:50:33.618071  135769 config.go:491] "Configured to push to Venafi" logger="Run" mode="Jetstack Secure API Token" reason="--api-token was specified"
        I0821 16:50:33.618111  135769 run.go:116] "Healthz endpoints enabled" logger="Run.APIServer" addr=":8081" path="/healthz"
        I0821 16:50:33.618123  135769 run.go:120] "Readyz endpoints enabled" logger="Run.APIServer" addr=":8081" path="/readyz"
        I0821 16:50:33.618140  135769 run.go:269] "Pod event recorder disabled" logger="Run" reason="The agent does not appear to be running in a Kubernetes cluster." detail="When running in a Kubernetes cluster the following environment variables must be set: POD_NAME, POD_NODE, POD_UID, POD_NAMESPACE"
        I0821 16:50:33.618149  135769 run.go:308] "Reading data from local file" logger="Run.gatherAndOutputData" inputPath="testdata/agent/one-shot/success/input.json"
        I0821 16:50:33.618224  135769 run.go:334] "Data saved to local file" logger="Run.gatherAndOutputData" outputPath="/dev/null"
        I0821 16:50:33.618246  135769 run.go:476] "Starting" logger="Run.APIServer.ListenAndServe" addr=":8081"
        I0821 16:50:33.618250  135769 run.go:490] "Shutting down" logger="Run.APIServer.ListenAndServe" addr=":8081"
        I0821 16:50:33.618295  135769 run.go:505] "Shutdown complete" logger="Run.APIServer.ListenAndServe" addr=":8081"

    agent_test.go:51: STDERR

--- PASS: TestAgentRunOneShot (0.03s)
PASS
ok      github.com/jetstack/preflight/cmd       0.064s

[wallrj-cyberark]

These deleted TODO comments were slightly inaccurate. What I meant was...if the agent is not running in a cluster, there's no Pod to attach events to, so the POD_NAME is not necessary.
And if the data is being read from a file, there are no K8S datagatherers, so KUBECONFIG should not be necessary. Nor is there a venafi-connection-lib to initialize, which is another reason KUBECONFIG is unnecessary.

[wallrj-cyberark]

And this deleted TODO comment should have said...--install-namespace is only necessary for initializing the venafi-connection-lib client, so it should not be necessary in this test.

[wallrj-cyberark]

I ran hack/e2e/test.sh, which uses venafi-connection mode and observed the Event being attached to the Pod:

$ kubectl describe pod -n venafi venafi-kubernetes-agent-69bdfddd8d-jcprb
...
    Args:
      agent
      -c
      /etc/venafi/agent/config/config.yaml
      --venafi-connection
      venafi-components
      --venafi-connection-namespace
      venafi
      --venafi-cloud
      --enable-metrics
      --logging-format=json
      --log-level=6
...
    Environment:
      POD_NAMESPACE:  venafi (v1:metadata.namespace)
      POD_NAME:       venafi-kubernetes-agent-69bdfddd8d-jcprb (v1:metadata.name)
      POD_UID:         (v1:metadata.uid)
      POD_NODE:        (v1:spec.nodeName)
...

Events:
  Type     Reason      Age    From                     Message
  ----     ------      ----   ----                     -------
  Normal   Scheduled   3m36s  default-scheduler        Successfully assigned venafi/venafi-kubernetes-agent-69bdfddd8d-jcprb to gke-richardw-eu-cluster--default-pool-407b409d-pdhs
  Normal   Pulling     3m36s  kubelet                  Pulling image "ttl.sh/a78a06e5-6677-47fb-9647-81eaa7f96f1c/venafi-kubernetes-agent/images/venafi-agent:v1.6.0-28-ga2e0a64ce23aa5"
  Normal   Pulled      3m32s  kubelet                  Successfully pulled image "ttl.sh/a78a06e5-6677-47fb-9647-81eaa7f96f1c/venafi-kubernetes-agent/images/venafi-agent:v1.6.0-28-ga2e0a64ce23aa5" in 4.147s (4.147s including waiting). Image size: 21154083 bytes.
  Normal   Created     3m32s  kubelet                  Created container: venafi-kubernetes-agent
  Normal   Started     3m31s  kubelet                  Started container venafi-kubernetes-agent
  Warning  PushingErr  3m26s  venafi-kubernetes-agent  retrying in 18.97738717s after error: post to server failed: while loading the VenafiConnection venafi/venafi-components: VenafiConnection.jetstack.io "venafi-components" not found

And the test passed:

$ ./hack/e2e/test.sh
...
{
  "ts": 1755792700826.4155,
  "caller": "transport/round_trippers.go:632",
  "msg": "Response",
  "v": 6,
  "logger": "Run.gatherAndOutputData",
  "verb": "POST",
  "url": "https://api.venafi.cloud/v1/tlspk/upload/clusterdata/no?description=QSBraW5kIGNsdXN0ZXIgdXNlZCBmb3IgdGVzdGluZyB0aGUgdmVuYWZpLWt1YmVybmV0ZXMtYWdlbnQuCg&name=venafi-kubernetes-agent-e2e",
  "status": "200 OK",
  "milliseconds": 971
}
{"ts":1755792700826.4617,"caller":"agent/run.go:444","msg":"Data sent successfully","v":0,"logger":"Run.gatherAndOutputData.postData"}
...
{
  "count": 1,
  "certificates": [
...      "certificateName": "venafi-kubernetes-agent-e2e.a2074131-f85a-48c0-88be-fb1a1d871a3b",
...
}
....
+ exit 0

[maelvls]

You are correct, --install-namespace was originally only meant to let venafi-connection-lib where to find the service account used to impersonate. I should have never triggered an error outside of the Venafi Connection mode, which it does now due to my "events" PR (#589).

Seems like I hijacked --install-namespace in #589, but that was somewhat stupid; I should have used POD_NAMESPACE instead of using --install-namespace. My mistake!!!

Thanks for the example log output, it looks good.