Difference between revisions of "Storlets/DataSecuritySpec"

Latest revision as of 18:58, 18 September 2016

Requirements

Allow the ability for an account admin to set read access using storlets. That is, allow access to a container only if the GET request has an appropriate X-Run-Storlet header, thus enforcing sensitive data filtering done with that storlet.

At this point we require that the feature will work with Keystone only, and that access will be granted on a single user basis only.

Added API

POST account/container

X-Storlet-Container-Read: user_name
X-Storlet-Name: storlet_name
X-Auth-Token: token

where:

The user name, is the name of the user as appearing in the user's Keystone token.
The storlet_name is the name as appearing in the X-Run-Storlet header, when invoking the storlet.
The token is a token of a user that is authorized to change a container ACL.

Usage

GET account/container

X-Run-Storlet: storlet_name
X-Auth-Token: token

where:

The storlet_name is the name of the storlet to invoke
The token is a token of a user that is:
- Authorized to read from the storlet container - no changes from today
- Authorized to read from the accessed container or was given explicit access to read using the specified storlet name using the above API.

Implementation

Since we want to allow the account admin to set this without the need to do Keystone updates, we utilize the Swift referrers mechanism: The internals of the above POST request adds to the targeted container read acl a referrer entry of the form: .r:org.openstack.storlet_internal.<user_name>_<storlet_name>

To prevent data leaks for users who put the concatenated referrer in their original request, the storlet_middleware blocks any request carrying a referrer that contains the internal prefix: org.openstack.storlet_internal.

Flow

The storlet middleware code will thus work as follows: 1. Make sure the incoming request (GET or HEAD) does not carry a referrer containing the internal prefix "org.openstack.storlet_internal" 2. For GET calls with X-Run-Storlet, try the existing path with no changes. 3. If the calls fails with status HTTPForbidden, we add to the request the internal referrer that is a concatenation of the authenticated user name and the storlet the user tried to execute. Once the referrer is added we retry the request.

This approach makes sure that the original user is an authenticated user with a valid token, and that the user was indeed granted access via the specified storlet.

@@ Line 8: / Line 8: @@
 * X-Storlet-Container-Read: user_name
 * X-Storlet-Name: storlet_name
+* X-Auth-Token: token
 where:
 * The user name, is the name of the user as appearing in the user's Keystone token.
-* The storlet_name is the mame as appearing in the X-Run-Storlet header, when invoking the storlet.
+* The storlet_name is the name as appearing in the X-Run-Storlet header, when invoking the storlet.
+* The token is a token of a user that is authorized to change a container ACL.
-Since we want to allow the account admin to set this without the need to do Keystone updates, we utilize the Swift referrer mechanism. Upon setting this, we add a referrer of the form:
+== Usage ==
-.r: org.apache.openstack.storlet_internal.<user_name>_<storlet_name>
+GET account/container
-This meant that under the hood we set the container read ACL, and so the operation will succeed only if the calling user has the appropriate role.
+* X-Run-Storlet: storlet_name
+* X-Auth-Token: token
-To prevent this internal setting of a referrer from causing anyone with a matching referrer header from gaining access, the storlet_middleware will block any request having a referrer header that contains org.apache.openstack.storlet_internal.
+where:
+* The storlet_name is the name of the storlet to invoke
+* The token is a token of a user that is:
+** Authorized to read from the storlet container - no changes from today
+** Authorized to read from the accessed container or was given explicit access to read using the specified storlet name using the above API.
+== Implementation ==
+Since we want to allow the account admin to set this without the need to do Keystone updates, we utilize the Swift referrers mechanism: The internals of the above POST request adds to the targeted container read acl a referrer entry of the form:
+.r:org.openstack.storlet_internal.<user_name>_<storlet_name>
-This, if an operator is to take the storlet_middleware out of the pipeline, after this API was called, the referrers added '''must''' be deleted.
+To prevent data leaks for users who put the concatenated referrer in their original request, the storlet_middleware blocks any request carrying a referrer that contains the internal prefix:  org.openstack.storlet_internal.
-== Changes in Flow ==
+== Flow ==
-When the proxy handler tries to do a GET with X-Run-Storlet that results in an "unauthorized" response, and the feature is enabled in the middleware config file, then it will re-attempt while adding the referrer header: org.apache.openstack.storlet_internal.<user_name>_<storlet_name>
+The storlet middleware code will thus work as follows:
-where the user name is taken from the identity env, and the storlet name from the X-Run-Storlet header.
+. Make sure the incoming request (GET or HEAD) does not carry a referrer containing the internal prefix "org.openstack.storlet_internal"
-In addition the middleware will check that the account in the url matches that of the authenticating user.
+. For GET calls with X-Run-Storlet, try the existing path with no changes.
+. If the calls fails with status HTTPForbidden, we add to the request the internal referrer that is a concatenation of the authenticated user name and the storlet the user tried to execute. Once the referrer is added we retry the request.
-These checks ensure that we are dealing with an authenticated user of the appropriate account.
+This approach makes sure that the original user is an authenticated user with a valid token, and that the user was indeed granted access via the specified storlet.