Currently the only exposed capability to use a lookup endpoint that requires authorization is to bake authorization credentials into the URL used as a lookup endpoint. go-nsq then makes a GET request to that endpoint during discovery.
Security best practice is to move authorization details to a header and out of the URL i.e. a Authorization: Bearer {Auth Secret} header.
This issue is to introduce new behavior where an AuthSecret when set is used as a Bearer token on lookupd calls. That seems like a sane default
LookupdAuthorization=false can be used to opt out of the new behavior (AuthSecret used on lookupd requests)
cc: @mreiferson @ploxiln in case you have any thoughts on this approach. I think our AUTH docs could use a little help, i'll try to build some better documentation of that.
mreiferson
commented
3 years ago
The
AUTHprotocol spec and nsqd AUTH details don't give much guidance for how to use AUTH with a lookupd endpoint (except implying thatnsqauthfilteris one approach).Currently the only exposed capability to use a lookup endpoint that requires authorization is to bake authorization credentials into the URL used as a lookup endpoint. go-nsq then makes a GET request to that endpoint during discovery.
Security best practice is to move authorization details to a header and out of the URL i.e. a
Authorization: Bearer {Auth Secret}header.This issue is to introduce new behavior where an AuthSecret when set is used as a Bearer token on lookupd calls. That seems like a sane default
LookupdAuthorization=falsecan be used to opt out of the new behavior (AuthSecret used on lookupd requests)cc: @mreiferson @ploxiln in case you have any thoughts on this approach. I think our AUTH docs could use a little help, i'll try to build some better documentation of that.