On Mon, Aug 25, 2014 at 5:03 PM, Vinod Kone <vinodk...@gmail.com> wrote: > See my answers inline. > > >> Based on what you say, looks like there are more HTTP endpoints (rw) >> exposed to slaves and frameworks, like /shutdown. We don't want to >> implement auth for these endpoints, atm. >> > > Yes. There are more user visible endpoints. See "master:port/help" for the > list of endpoints. > > That said, i think, we should authenticate /master/state.json only. >> Can I assume, this can be implemented in Master::Http::state method, >> using process::http::Request and process::http::Response? Or, does >> slave/framework use /master/state.json endpoint? Any changes to this >> method will not affect protobuf message exchange between master and >> slave/framework, I think. Correct me if i'm wrong. >> > > For authorizing static http endpoints, we could resurrect some code that > didn't make it into 0.20.0. See the diff here ( > https://github.com/apache/mesos/commit/a5cc9b435aad080a79230f0366a6ce77116c95a4) > and let me know if that is what you are looking for.
It's more for authorizing frameworks. We looking for authenticating users for certain HTTP endpoints. If i understand right, the above patch expect certain authz credentials like principal & role for framework registration and principal & user for running tasks. For web requests, i don't think angularJS is exchanging any credential or query-param with master. It's always GET specific json. We are thinking to solve this problem by running a proxy in front of each mesos master and implement authN based on path and/or User-Agent. We'll keep you posted if we want any changes to be made in mesos. > Note, the HTTP endpoints exposed by master for web requests do not impact > the internal HTTP endpoints used for communicating with frameworks/slaves. Good to know. This will make our implementation simple, as we don't want to authenticate HTTP requests from frameworks/slaves. Thank you, -- Regards, Bhuvan Arumugam www.livecipher.com
