It's the reverse proxy we've discussed for the "micro services" version for a while now (as in https://cwiki.apache.org/confluence/display/TC/Design+Overview+v3.0).
On Sun, May 7, 2017 at 7:22 PM Eric Friedrich (efriedri) <[email protected]> wrote: > From a higher level- what is purpose of the API Gateway? It seems like > there may have been some previous discussions about API Gateway. Are there > any notes or description that I can catch up on? > > How will it be deployed? (Is it a standalone service or something that > runs inside the experimental Traffic Ops)? > > Is this new component required or optional? > > —Eric > > > > > On May 7, 2017, at 8:28 PM, Jan van Doorn <[email protected]> wrote: > > > > I looked into this a year or so ago, and I couldn't make nginx or http do > > what we need. > > > > We can still have the services check the auth as well after the proxy > auth, > > and make things better than today, where we have the same problem that if > > the TO mojo app is compromised, everything is compromised. > > > > If we always route to TO, we don't untangle the mess of being dependent > on > > the monolithic TO for everything. Many services today, and more in the > > future really just need a check to see if the user is authorized, and > > nothing more. > > > > On Sun, May 7, 2017 at 11:55 AM Robert Butts <[email protected]> > > wrote: > > > >> What are the advantages of these config files, over an existing reverse > >> proxy, like Nginx or httpd? It's just as much work as configuring and > >> deploying an existing product, but more code we have to write and > maintain. > >> I'm having trouble seeing the advantage. > >> > >> -1 on auth rules as a part of the proxy. Making a proxy care about auth > >> violates the Single Responsibility Principle, and further, is a security > >> risk. It creates unnecessary attack surface. If your proxy app or > server is > >> compromised, the entire framework is now compromised. An attacker could > >> simply rewrite the proxy config to make all routes no-auth. > >> > >> The simple alternative is for the proxy to always route to TO, and TO > >> checks the token against the auth service (which may also be proxied), > and > >> redirects unauthorized requests to a login endpoint (which may also be > >> proxied). > >> > >> The TO service (and any other service that requires auth) MUST hit the > >> database (or the auth service, which itself hits the database) to verify > >> valid tokens' users still have the permissions they did when the token > was > >> created. Otherwise, it's impossible to revoke tokens, e.g. if an > employee > >> quits, or an attacker gains a token, or a user changes their password. > >> > >> > >> On Sun, May 7, 2017 at 4:35 AM, Amir Yeshurun <[email protected]> wrote: > >> > >>> Seems that attachments are stripped on this list. Examples pasted below > >>> > >>> *rules.json* > >>> [ > >>> { "host": "localhost", "path": "/login", "forward": > >>> "localhost:9004", "scheme": "https", "auth": false }, > >>> { "host": "localhost", "path": "/api/1.2/innovation/", "forward": > >>> "localhost:8004", "scheme": "http", "auth": true, "routes-file": > >>> "innovation.json" }, > >>> { "host": "localhost", "path": "/api/1.2/", "forward": > >>> "localhost:3000", "scheme": "http", "auth": true, "routes-file": > >>> "traffic-ops-routes.json" }, > >>> { "host": "localhost", "path": "/internal/api/1.2/", "forward": > >>> "localhost:3000", "scheme": "http", "auth": true, "routes-file": > >>> "internal-routes.json" } > >>> ] > >>> > >>> *traffic-ops-routes.json (partial)* > >>> . > >>> . > >>> . > >>> { "match": "/cdns/health", "auth": { "GET": > >>> ["cdn-health-read"] }}, > >>> { "match": "/cdns/capacity", "auth": { "GET": > >>> ["cdn-health-read"] }}, > >>> { "match": "/cdns/usage/overview", "auth": { "GET": > >>> ["cdn-stats-read"] }}, > >>> { "match": "/cdns/name/dnsseckeys/generate", "auth": { "GET": > >>> ["cdn-security-keys-read"] }}, > >>> { "match": "/cdns/name/[^\/]+/?", "auth": { "GET": > >>> ["cdn-read"] }}, > >>> { "match": "/cdns/name/[^\/]+/sslkeys", "auth": { "GET": > >>> ["cdn-security-keys-read"] }}, > >>> { "match": "/cdns/name/[^\/]+/dnsseckeys", "auth": { "GET": > >>> ["cdn-security-keys-read"] }}, > >>> { "match": "/cdns/name/[^\/]+/dnsseckeys/delete", "auth": { "GET": > >>> ["cdn-security-keys-write"] }}, > >>> { "match": "/cdns/[^\/]+/queue_update", "auth": { "POST": > >>> ["queue-updates-write"] }}, > >>> { "match": "/cdns/[^\/]+/snapshot", "auth": { "PUT": > >>> ["cdn-config-snapshot-write"] }}, > >>> { "match": "/cdns/[^\/]+/health", "auth": { "GET": > >>> ["cdn-health-read"] }}, > >>> { "match": "/cdns/[^\/]+/?", "auth": { "GET": > >>> ["cdn-read"], "PUT": ["cdn-write"], "PATCH": ["cdn-write"], "DELETE": > >>> ["cdn-write"] }}, > >>> { "match": "/cdns", "auth": { "GET": > >>> ["cdn-read"], "POST": ["cdn-write"] }}, > >>> > >>> . > >>> . > >>> . > >>> > >>> > >>> On Sun, May 7, 2017 at 12:39 PM Amir Yeshurun <[email protected]> wrote: > >>> > >>>> Attached please find examples for forwarding rules file (rules.json) > >> and > >>>> the authorization rules file (traffic-ops-routes.json) > >>>> > >>>> > >>>> On Sun, May 7, 2017 at 10:39 AM Amir Yeshurun <[email protected]> > wrote: > >>>> > >>>>> Hi all, > >>>>> > >>>>> I am about to submit a PR with a first operational version of the API > >>> GW, > >>>>> to the "experimental" code base. > >>>>> > >>>>> The API GW forwarding logic is as follow: > >>>>> > >>>>> 1. Find host to forward the request: Prefix match on the request > >> path > >>>>> against a list of forwarding rules. The matched forwarding rule > >>> defines the > >>>>> target's host, and the target's *authorization rules*. > >>>>> 2. Authorization: Regex match on the request path against a list of > >>> *authorization > >>>>> rules*. The matched rule defines the required capabilities to > >> perform > >>>>> the HTTP method on the route. These capabilities are compared > >>> against the > >>>>> user's capabilities in the user's JWT > >>>>> > >>>>> At this moment, the 2 sets of rules are hard-coded in json files. The > >>>>> files are provided with the API GW distribution and contain > >> definitions > >>> for > >>>>> TC 2.0 API routes. I have tested parts of the API, however, there > >> might > >>> be > >>>>> mistakes in some of the routes. Please be warned. > >>>>> > >>>>> Considering manageability and high availability, I am aware that > using > >>>>> local files for storing the set of authorization rules is inferior to > >>>>> centralized configuration. > >>>>> > >>>>> We are considering different approaches for centralized > configuration, > >>>>> having the following points in mind > >>>>> > >>>>> - Microservice world: API GW will front multiple services, not only > >>>>> Mojo. It can also front other TC components like Traffic Stats and > >>> Traffic > >>>>> Monitor. Each service defines its own routes and capabilities. Here > >>> comes > >>>>> the question of what is the "source of truth" for the route > >>> definitions. > >>>>> - Handling private routes. API GW may front non-TC services. > >>>>> - User changes to the AAA scheme. The ability for admin user to > >> makes > >>>>> changes in the required capabilities of a route, maybe even define > >>> new > >>>>> capability names, was raised in the past as a use case that should > >> be > >>>>> supported. > >>>>> - Easy development and deployment of new services. > >>>>> - Using TO DB for expediency. > >>>>> > >>>>> I would appreciate any feedback and views on your approach to manage > >>>>> route definitions. > >>>>> > >>>>> Thanks > >>>>> /amiry > >>>>> > >>>> > >>> > >> > >
