Credentials within nats messages

[John McTeague]

If I subscribe to NATS and pull down every message, I occasionally see messages like:

Msg received on [_INBOX.457425859d026a10077bdf7f9c] : '{"type":"uaa","host":"172.16.3.158:8080","index":0,"uuid":"0-4237b954-0d2b-455d-8ddc-d61d4edccfd4","credentials":["24163-27328-1211-11661","14609-13584-16675-1094"]}'
Msg received on [_INBOX.457425859d026a10077bdf7f9c] : '{"type":"etcd","index":0,"host":"172.16.3.152:5678","uuid":"0-","credentials":["oAQBwVCBCpIodaOvk_h0GQwURRkdpVvxttVuLk4iFRdt9skSQVgdZ8iT","ocSmFJe3oFVKIf1XBtJpmGOlPjdd88Qjcv64N3ViEyq7GtKcAiMvt8lK"]}'
Msg received on [_INBOX.457425859d026a10077bdf7f9c] : '{"type":"CloudController","index":0,"uuid":"0-0f85dc2a139947ab89bd2e5683961c12","host":"172.16.3.162:57444","credentials":["1c6270ebf9404ff6b17aa11d750a3498","b0a87ed7d3e84cf995016ec0c37b7f57"],"start":"2015-04-15T17:43:17+00:00","uptime":"7d:17h:11m:51s"}'
Msg received on [_INBOX.457425859d026a10077bdf7f9c] : '{"type":"Router","index":0,"host":"172.16.3.176:8080","credentials":["gorouter","*******"],"uuid":"0-aca72545-9cb5-417e-775c-b937f89ec69c","start":"2015-03-30 13:26:28 +0000","uptime":"23d:21h:28m:39s"}'

The fact that plain text credentials are being passed around within NATS is a concern. Equally, I have no idea what most of these credentials are for (the gorouter one I recognise as the router status account.

Can I get some clarification on these messages?

[James Bayer]

these messages are responses to the collector "discover" message. these enable the collector to invoke the /varz basic auth protected endpoints of system components to retrieve system component metrics. the /varz endpoints are intended for read-only monitoring.

the architecture of cf is moving away from both the collector pattern for metrics and NATS as a broadcast communication channel. for example, notice that the only place diego has NATS is the last mile to the router. there has been an entire track of router work to add an http api for the router and we're hoping to move to adopt similar communication patterns the diego team has been using with http streaming and HA state stores throughout runtime.

we're moving toward loggregator for transporting metrics for system components in addition to apps using a push vs a pull pattern.

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/8b55fdea-af53-44b4-9fa9-c33d9047c29b%40cloudfoundry.org.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

--

Thank you,

James Bayer

[Camilo Aguilar]

What is it going to be used instead of NATS?

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAB%3Dt-sUtExLjh_6_KLgakYpNkWH9T9dur4r6wTQtMRN_TKx7uw%40mail.gmail.com.

[James Bayer]

in diego http features are used, things like Server Sent Events to minimize cost of connection negotiation and things like etcd and consul underneath for sharing. we don't have all the answers yet, but will likely figure something out over the next few months.

To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAO711iS3wPbLowxEBo5eDwcRFrrJK0G4UfdeY7LsuoJNaTg8Yw%40mail.gmail.com.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.