Make CM update it's own permissions before requests are proxied to other containers

[yousefamar]

I didn't realise that Hypercat was ahead of CM-in-docker since pushing directly upstream doesn't send notifications like PRs do, so was only looking at the changes now. I merged both branches locally and will PR on Monday to prepare to close #19 if nobody's on that ATM.

All looks great! One thing to note though is that this won't work because the arbiter doesn't differentiate between keys coming from the CM or from other containers. It will be double broken once we close https://github.com/me-box/databox-arbiter/issues/8 since the arbiter won't mint tokens for something without being told by the CM what it's permissions are, even if that something is the CM itself.

The easiest solution would be to hardcode a condition that enables the CM (or something using the CM's key, aka the ARBITER_KEY environment variable) to request whatever macaroon it wants, kind of like making it root. But I don't think that would be a good/safe idea.

So to make this work, what I think should be done before the CM requests macaroons from the arbiter, is for it to request /cm/upsert-container-info and pass it's key to the arbiter, registering itself into arbiter records (the same way it would do for normal containers).

If you're wondering "why not have the arbiter just do that on start-up since it has the CM's ARBITER_KEY anyway?", that's because this will work only until we resolve https://github.com/me-box/databox-arbiter/issues/8. After that, it will also need to tell the arbiter what routes it wants access to. These shouldn't necessarily be /* across the board, but only the routes that the CM actually expects to proxy, or request itself, e.g. / (config UI?), /cat, /status etc.

[Toshbrown]

Morning,

Running the CM in docker got more involved than I expected. There are issues around how the networking is configured within a container so I've stopped work on this for now. We should pick this up again later.

I Think there is a larger question about how and where certain system component permissions are encoded and passed to the arbiter. Which we need to deal with alongside me-box/databox-arbiter#8.

Are you available for a skype today?

Cheers

Tosh

[yousefamar]

Sounds good! I'm around all day, just ping me whenever you're free. I don't think I have you on Skype: https://join.skype.com/gakGWORSBCZd.

Edit: If today's no-go, tomorrow any time works too (e.g. 14:00?).

[yousefamar]

I Think there is a larger question about how and where certain system component permissions are encoded and passed to the arbiter. Which we need to deal with alongside me-box/databox-arbiter#8.

So I'm thinking this would go something like:

1. User interacts with UI
2. CM queries arbiter/cat, walks store items
3. CM presents to user, who interacts with UI some more to build SLA
4. CM takes SLA, turns it into routes
5. CM passes these to arbiter (which the arbiter builds into macaroons as caveats)
6. User changes their mind later or whatever, interacts with UI
7. CM updates or deletes arbiter records (I actually added a way to do the latter in my latest PR)

So the part that this issue would be relevant to is before all of that. Step 2 (specifically the second half) would fail because the stores would reject those requests. The missing steps that could go before those above to resolve this are:

1. CM launches arbiter
2. CM POSTs to arbiter/cm/upsert-container-info with it's own key and routes (including /*/cat or global wildcard) a. This can be made even less permissive by instead POSTing the route /[some-store]/cat etc. every time a new store is launched instead.
3. Only then can CM ask for macaroon, that it can use with the previous step 2.

This all applies to any other store endpoints that the CM might need to query for whatever reason (not just store/cat).

[haddadi]

This seems to be an issue still. Worth attending it before the 9th Feb meeting? I hope we can integrate the permission setting in the UI meeting next week cheers

[Toshbrown]

fixed in 64c5af0aadb93a25bb1b8fc26f463781238530a4