Am i right in thinking that the bottlerocket OS does not need any ports open to be accessible from BottleRocket Update Operator?

[landbaychrisburrell]

Hi

My understanding is that most of the interactions between the operator and the BottleRocket OS happen by updating the Shadow resources - as such, there is presumably zero ports required to be open - and so locking down the namespace with a policy that prevents all comms for pods into the operator's namespace would be fine?

[cbgbt]

Hello,

It's worth noting that the agent pods do not directly modify the Shadow resources. Instead, they reach out to the apiserver pods via https, which authorize that the shadows are only being modified by the appropriate agent. More details about this can be found in the design document.

The only other open ports are for exposing prometheus metrics from the apiserver and controller pods.

I hope this helps, let me know if I can help clarify anything else!

[stockholmux]

@landbaychrisburrell FYI I created an issue about this for the upcoming brupop documentaiton bottlerocket-os/bottlerocket-project-website#406

[landbaychrisburrell]

Thanks - much appreciated.

Just on the note above, do you know if there's any documentation about which metrics are in fact exposed to Prometheus? I found the GitHub issue but not sure if that's the best location. In particular, I don't know if it's available, but the seed number of each node would be valuable. That, together with which 'versions are available to a node would allow better forecasting of upgrades and could help users set up alerting when new upgrades are due but the schedule hasn't yet reached.

I guess they don't 'naturally' fit into Prometheus (e.g. not really a time-series) but they would be valuable monitoring insights.

(separately, it might be nice to add a PodMonitor to the helm chart)