Add SPIRE connection to status

[meyskens]

This adds the SPIRE connection to cilium status, this then can be used by the CLI tool to surface errors and/or wait for SPIRE to be ready. If Auth is disabled it will surface the disabled status.

Fixes: cilium/cilium-cli#1821

Add SPIRE connection to `cilium status`

[mhofstetter]

@meyskens Thanks for the PR. I like the idea of leveraging the status for the cilium status instead of checking the SPIRE deployment directly.

I left some thoughts inline.

Overall i think the concept of the recently introduced HealthReporter would fit here quite well. It looks really promising. It already provides an easy way to report the health status of a hive module by injecting an instance of a HealthReporter. AFAIK, until now, it only lacks support for exposing the reported health status (e.g. via cilium status API).

But the bits for fetching the data are already prepared in the Health interface. IMO it should be possible that the daemon depends on the Health interface and adds a status probe for all registered modules by calling All(). This way the daemon doesn't have to be directly dependent on something "auth-related" at all.

I'm aware of the fact that this should land in v1.14. But I thought it's worth to bring this up and I'd like to have the input of @tommyp1ckles (maybe there's already something in the pipeline)

[mhofstetter]

some small optimizations regarding comments.

But it looks like there's a lint-error -> Please run make generate-k8s-api & make manifests and submit your changes

[tommyp1ckles]

@meyskens @mhofstetter From the changes this does look a lot like a module health status, the only difference being that the status is checked when the status endpoint is called, the health reporter status would likely be emitted when there is a change of health status state or on some periodic loop (preferably on a reconciliation loop/controller).

Right now the status of the health reporting is that we don't have the new Agent API health reporter endpoint in v1.14.

However the health status reporter updates can still be accessed via debug logging so there may be value in doing that (we could make the case for bumping that to info level in that case).

If you are interested in eventually adding health reporting lmk and I can provide more details. For the time being I probably recommend doing the changes in this PR and having the health reporting be supplementary.

[meyskens]

/test

[mhofstetter]

LGTM, thanks for the changes @meyskens

[meyskens]

Rebased for the conflict with ipcahce changes on main

[meyskens]

/test

[youngnick]

The runtime test failed to copy the Ginkgo binary? I'll retest.

/test

[youngnick]

/test

[tklauser]

@meyskens I've tried to backport this PR to v1.14 as part of the backporter rotation but hit some non-trivial merge conflicts. Would you be ok to backport this yourself given you're more familiar with the code in question? Thanks

[meyskens]

Will do!

[michi-covalent]

i guess this didn't get moved to backport-done/1.14. trying to figure out how to manually fix it 🧠