You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by 甯尤刚 <ni...@navercorp.com> on 2019/01/23 02:57:13 UTC
[discuss]Add protect feature to avoid update or delete actions by mistake
As more and more production system uses openwhisk,
It seems we need some feature to protect their service safe from mistake.
for example, when users create action use like below(add annotation "lock":true)
curl -X PUT -H "Content-type: application/json" --user 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP -d '{"namespace":"guest","name":"hello","annotations":[{"key":"lock","value":true}],"exec":{"kind":"nodejs:default","code":"// Licensed to the Apache Software Foundation (ASF) under one or more contributor\r\n// license agreements; and to You under the Apache License, Version 2.0.\r\n\r\n/**\r\n * Hello, world.\r\n */\r\nfunction main() {\r\n return {\"payload\":\"Hello world\"};\r\n}\r\n"}}' 'http://xxx.xxx.xxx.xxx:port/api/v1/namespaces/guest/actions/hello?'
The lock field will be added in couchdb's annotation, like below
"annotations": [ { "key": "exec", "value": "nodejs:6" }, { "key": "lock", "value": true }
So this action can't be deleted/updated until the protection is updated to false
This is the patch: https://github.com/apache/incubator-openwhisk/pull/4058
If this patch is merged into upstream, the wsk side will do some changes, add unlock feature to wsk to enable update or delete operation, for example
wsk action update hello --unlock
So we can discuss there, is it necessary to add this feature? or any other suggestions.
[discuss]new design of granular permission management
Posted by 甯尤刚 <ni...@navercorp.com>.
Hi, guys.
for the pr: https://github.com/apache/openwhisk/pull/4058, the initial target is just `Add protect feature to avoid update or delete actions by mistake`
It seems there has another option to do `granular permission management`, we can do it better.
Below points is my new design for it.
#### 1. There is no need to add permissions controls for action's "owner" since he/she can anyway update/remove/invoke his/her action.
#### 2. It is necessary to control other shared user's permission (e.g. whether has permission to read/download the codes, whether has permission to execute the codes), this separate document in db: `xxx_permission` may like below
```
{
"_id": "whisk.system/helloAction",
"_rev": "1-1a14818c1083bc12b6d3fd1774fcc956",
"default": {
{
"read" : false
"execute": false
}
}
"permission": {
"theSharedUserA": {
"read" : yes
"execute": yes
},
"theSharedUserB": {
"read" : yes
"execute": false
}
}
```
Regarding above permission document of `whisk.system/helloAction`
* when create action: `whisk.system/helloAction`, the owner can set default read/execute permission. e.g.
```
"default": {
{
"read" : false
"execute": false
}
}
```
* the shared user will inherits the default permissions if not explicitly specified in above document. e.g.
not explicitly specified for theSharedUserC, so theSharedUserC will have default permission
* if explicitly specified in above document for the shared user, the shared user will have specified permission, e.g.
already explicitly specified for theSharedUserA, so theSharedUserA's permission is
```
"theSharedUserA": {
"read" : yes
"execute": yes
}
```
I also wrote it here: https://github.com/apache/openwhisk/pull/4058#issuecomment-851116337
Have any new idea or suggestion?
-----Original Message-----
From: "甯尤刚"<ni...@navercorp.com>
To: <de...@openwhisk.apache.org>;
Cc:
Sent: 2019/1/23周三 10:57 (GMT+08:00)
Subject: [discuss]Add protect feature to avoid update or delete actions by mistake
As more and more production system uses openwhisk,
It seems we need some feature to protect their service safe from mistake.
for example, when users create action use like below(add annotation "lock":true)
curl -X PUT -H "Content-type: application/json" --user 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP -d '{"namespace":"guest","name":"hello","annotations":[{"key":"lock","value":true}],"exec":{"kind":"nodejs:default","code":"// Licensed to the Apache Software Foundation (ASF) under one or more contributor\r\n// license agreements; and to You under the Apache License, Version 2.0.\r\n\r\n/**\r\n * Hello, world.\r\n */\r\nfunction main() {\r\n return {\"payload\":\"Hello world\"};\r\n}\r\n"}}' 'http://xxx.xxx.xxx.xxx:port/api/v1/namespaces/guest/actions/hello?'
The lock field will be added in couchdb's annotation, like below
"annotations": [ { "key": "exec", "value": "nodejs:6" }, { "key": "lock", "value": true }
So this action can't be deleted/updated until the protection is updated to false
This is the patch: https://github.com/apache/incubator-openwhisk/pull/4058
If this patch is merged into upstream, the wsk side will do some changes, add unlock feature to wsk to enable update or delete operation, for example
wsk action update hello --unlock
So we can discuss there, is it necessary to add this feature? or any other suggestions.
Re: [discuss]Add protect feature to avoid update or delete actions by mistake
Posted by Rodric Rabbah <ro...@gmail.com>.
I posted a comment on the issue but for the benefit of the dev list: I
think the implementation points to a more general permission set on an
action. In the noted PR, it is strictly a "write" permission for the
namespace (like a group in UNIX terminology), and one can image an execute
permission as well next (disables an action from executing for a
namespace). I'm not sure if a read permision makes sense here since its per
namespace still.
So my thoughts is whether to factor the permission more generally to allow
for generalization later... or leave it as is and change it later to add
execute permission - does that even make sense (to "pause" an action from
executing).
-r
On Tue, Jan 22, 2019 at 9:57 PM 甯尤刚 <ni...@navercorp.com> wrote:
> As more and more production system uses openwhisk,
> It seems we need some feature to protect their service safe from mistake.
>
> for example, when users create action use like below(add annotation
> "lock":true)
> curl -X PUT -H "Content-type: application/json" --user
> 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP
> -d
> '{"namespace":"guest","name":"hello","annotations":[{"key":"lock","value":true}],"exec":{"kind":"nodejs:default","code":"//
> Licensed to the Apache Software Foundation (ASF) under one or more
> contributor\r\n// license agreements; and to You under the Apache License,
> Version 2.0.\r\n\r\n/**\r\n * Hello, world.\r\n */\r\nfunction main() {\r\n
> return {\"payload\":\"Hello world\"};\r\n}\r\n"}}'
> 'http://xxx.xxx.xxx.xxx:port/api/v1/namespaces/guest/actions/hello?'
> The lock field will be added in couchdb's annotation, like below
> "annotations": [ { "key": "exec", "value": "nodejs:6" }, { "key": "lock",
> "value": true }
> So this action can't be deleted/updated until the protection is updated to
> false
>
> This is the patch: https://github.com/apache/incubator-openwhisk/pull/4058
>
> If this patch is merged into upstream, the wsk side will do some changes,
> add unlock feature to wsk to enable update or delete operation, for example
>
> wsk action update hello --unlock
> So we can discuss there, is it necessary to add this feature? or any other
> suggestions.
>
>