Re: Securing Action Container communication
A solution should be built into the core, absolutely! There may be more than one approach but at least an outline of a solution should be incorporated into the deployments we support. As Markus noted on slack, one way to isolate the action containers is through a docker network that forbids inter-container communication with iptables. Jeremias could probably talk more about this as a starting point. -r
Securing Action Container communication
I'm starting this thread based on our conversations in Slack [1]. This is a sensitive aspect, at least 2 folds: 1. Container isolation. making sure action containers can't invoke other containers directly, nor other system components directly (db, kafka, kube api, mesos api). What are the best ways to achieve this ? 2. Protecting restricted data on transit: securing the data plane communication via SSL from controller -> kafka -> invoker -> action container. Do we want to build this into the project, or treat it optional and only document it ? Either way, it would be great to brainstorm together on what are the best approaches. WDYT ? Let's share our thoughts here, and then create issues for the items that we want to implement in OpenWhisk; if we want to treat some aspects optional, we can at least open issues to document possible approaches ? Thanks, dragos [1] - https://openwhisk-team.slack.com/archives/C3TPCAQG1/p150670440446
activations list and filtering by package name
There's an open issue [1] about listing activations and filtering by name of the action within a package. This is not something that works today. The reason is that the index computed for activations appends the short name of the action, eliding the package name if it exists. The views which compute the indexes for activations and actions now have some redundancies - dating back to when the documents were mixed in a single database, and there was support for listing public packages. I took the opportunity to clean these views up in [2]. While doing that, I'm wondering if I should also address [1]. One way to do that is change the index to normalize the search key so that the full name of the action can be used. This will permit actions in packages to be listed by their activations. There is an asymmetry however in that actions in the default package do not name an explicit or implicit package. With web actions, I addressed part of this asymmetry, but requiring actions to always be fully qualified, and using the word "default" to refer to an action in the default package. I'd like to extend this change to filtering activation lists by action name. So that, filtering for an action "A" in the default package requires the key: "default/A", and for an action "B" in a package "P" requires the key "P/B". I've suggested this in a comment here [3]. The "default" prefix could be sugared in the CLI, or even in the API (not my preference), to preserve existing behavior. [1] https://github.com/apache/incubator-openwhisk/issues/1635 [2] https://github.com/apache/incubator-openwhisk/pull/2760 [3] https://github.com/apache/incubator-openwhisk/pull/2760#issuecomment-333138595 I'm soliciting feedback and suggestions. -r
