ability to specify subject as namespace owner to manage other subjects in a namespace.

[neerajmangal]

Enhancement:

Ability to mention a subject as a owner when provisioning namesapce.

Currently only the administrator who is having access to openwhisk boot instance (wskadmin cmd) able to manage users and namespaces. Enhancement is to configure a user as owner of namesapce who can further configure/provision other users in his team to deploy and manage functions. It is also helpful further to expose new PUT APIs for namespace to provision users for owner in owned namespace as currently only Get All Namespace and Get Namespace is available.

For example, we are creating namespaces per team and want to have functionality for one or more team members to add other team members in that namesapce.

Please let me know if that is currently achievable which I am missing and has any security impacts.

• This will help in developing web applications to manage namespaces remotely leveraging namesapce PUT APIs.
• Further in future, can be think of making tenant based approach to manage namespaces.

Please let me know your suggestions.

[markusthoemmes]

A few thoughts on this:

In general, we always viewed OpenWhisk as not managing any of those namespaces. The wskadmin command is merely a stopgap so it's possible to create subjects and namespaces and everything.

In general, the advice is, that you can build your very own service for your project, which handles the user management in any way you like. That service can adjust the subjects database to your specific needs. It doesn't need to be part of OpenWhisk's core functionality (at least from my PoV).

[rabbah]

That said - historically that was a route in the controller namespace API handler to create a new subject/namespace/key. As it stands the controller is only a reader of the subject database, not a writer, and over time we've removed all the code that writes to the subject database.

If you were to add such a route/support back, you'll need to implement some dedicated ACL for it so that only privileged subjects may create/delete/revoke keys.

[neerajmangal]

@markusthoemmes and @rabbah, thanks for the response. I agree on your points.

We are developing web UI using Openwhisk APIs, for action developers to create and manage their actions apart from wsk CLI.

For user and namespace management specifically, we have created an another light weight external service (python+flask), which expose custom APIs to manage few operations on UI like getting all namespaces associated with user, checking if user is part of any given namespace, adding user to sandbox (default) namespace if user logged in first time to UI etc.

This service does not directly call the couch DB APIs to do these operations, instead custom APIs leverage/depend-on 'wskadmin' command for these operation (as wskadmin already does call the couchdb APIs internally). We also deployed this service on boot instance as part of our openwhisk deployment (where wskadmin command is available) via ansible using the existing deployment framework for our needs.

I agree and it is fine, not to support 'create' operation in namespace controller, given the fact that namespace controller is only reader of subjects. But can we support a flag/option in wskadmin command to specify a user as owner of the namespace while creating namespace, that way we can extend our UI and service to enable namespace owners to manage other subjects.

I can try to do a poc on this. Let me know your suggestions and feedback.

Thanks, Neeraj

[rabbah]

If you’re standing up a microservice to do this why bother using wskadmin at all? It just makes API calls to couchdb; can you just do that instead (you can reuse wskadmin’s methods perhaps but not the cli aspect. Maybe that’s what you’re doing already?) if you make direct API calls to couchdb then you can create whatever schema you need.

When you said flask I wondered why not actually used openwhisk actions to do this. You can surface those actions as webactions hence an API and can implement ACL within the action. The. You deploy these actions as part of the boot up process.