| Hi Rob, Thanks for coming back to us. In our case actually, as explained by David, we only need to add custom headers to the requests sent by the agents when they chat to the Puppet servers. It'd be perhaps interesting to configure the HTTP client to restrict what type of requests will be modified (by path, for instance) but indeed it's not worth to spend time on this due to how the client is implemented. This is totally an agent-oriented change proposal. In our case our agents only talk to the Puppet servers so to make use of this new feature the only thing that we had to do configuration-wise was to add the new setting to the [agent] section of the puppet.conf available on the agents and that was it. Puppet servers were left untouched as we don't need them to send any extra headers to any endpoint. I personally don't see a risk if the default behavior is to not to send anything extra so nothing changes, that indeed combined with a good description in the documentation. Obviously administrators could send anything they wanted but that's their choice. On top of that, there's nothing harmful that you could naively do (like when using a switch), users must explicitly configure what data to send in those arbitrary headers. Overloading the User-Agent could be a solution but I think it's far from being elegant. Actually we're already using that header for something else and adding non-standard data there could be painful as it'd require doing some post-processing on our monitoring pipelines to remove undesired stuff. We cannot provide much more information than what has been described in previous posts, not because we can't share more details but because there isn't much more really. We want to send metadata from the agent side that will be consumed by the ingress layer to make routing decisions. As Puppet talks HTTP we think that HTTP headers is a good fit for this. Using extended attributes in the client's certificate is unfortunately not an option for us at the moment. This new feature was born in the context of deploying our masters on Kubernetes clusters, however it could be useful in many more situations outside of the containers world. |
