Keystone/Service-Isolation-And-Roles-Delegation

OpenStack Service Isolation and Roles Delegation

(Draft 1 – November 12th, 2012)

Proposed by: Marek Kisielewicz

Thank you for feedback from: Jason Rouault

Please see the Etherpad at

https://etherpad.openstack.org/service-endpoint-isolation-role-delegation

for a critical appraisal of this design by David Chadwick

Problem Statement

The current model for validation Keystone tokens by OpenStack services using the middleware does not provide sufficient isolation of services. Scoping of tokens to a tenant/project level is not sufficient to isolate services and to prevent services from using the tokens issued by Keystone and scoped for a tenant to be used by services for accessing user’s resources on other services within the same tenant. Once the user passes a token to a service the user loses control on how the token is used by a service. The services may use the tokens provided by a user to access other services and confidential information without user’s knowledge. In some cases, this is a desired behavior where a service really needs to access some resources on another service on user’s behalf. However, the end user must explicitly grant permissions for using of his/her token to access other services.

Recommended Solution

The solution for the above problem includes the following primary changes in the Keystone model for token issuing and validation.

1. The tokens need to be scoped to a service level and optionally to an endpoint level. The services must accept only tokens scoped for their service ID. The services must also check if the endpoint for which the token is scoped matches the endpoint they are serving if scoping is narrowed down to a particular endpoint.

2. The user should be allowed to explicitly grant permissions for the service the token is scoped for to use a subset of his/her roles on another service within the same tenant. This can be accomplished by delegating the subset of roles the user has on a target service to another service.

3. Each OpenStack service which accepts signed token needs to have an account in Keystone. This account needs to contain at least one valid encryption key, either symmetric or asymmetric, or a valid X.509 certificate. The account owner can designate one or more keys that will be used to encrypt token data for its service. The owner can designate a separate encryption key per service endpoint to allow for more granular isolation on an endpoint level, when needed.

This solution would allow for separation of services using either signed or unsigned tokens.

Delegation of service roles

The Keystone services API would need to be extended to allow users to grant and revoke roles they have on a service to be used by another service. The API should allow for specifying optional time constraints for delegation of roles.

Service isolation and delegation of roles with unsigned tokens

The diagram below shows an example of using tokens scoped to service level with delegation using unsigned tokens.

In the example above, a user delegates the roles he has on the service T to the service S. No roles on service X are delegated to S. This is done before the user attempts to access any resources on the service S.

Then, the user acquires a token scoped for a tenant and service S. Keystone returns a token which includes only the endpoints and roles for selected service. Then the user passes the token to the service S. The request is intercepted by middleware and token is sent for validation to Keystone, which returns the roles of the user on service S. When the service S calls service T on behalf o user it passes the same token to T, which in turn calls Keystone to validate it. In that case, Keystone uses the service ID of the token it was scoped to, in this case S, returns the roles of user on service T based on the granted delegation of roles from service T to S. When a malicious service S attempts to use a service X for which the user did not grant any delegated roles, keystone will reject the request since the token was scoped for service S with no role delegated for service S to service T.

Service isolation and delegation of roles with signed tokens

The diagram below shows an example of using service scoped tokens with delegation using signed tokens

As in the previous the example, a user delegates the roles he has on the service T to the service S. No roles on service X are delegated to S. This is done before the user attempts to access any resources on the service S.

Then, the user acquires a token scoped for a tenant and the service S. When a signed token is requested, Keystone will create a multi-part token, with parts encrypted for separate services and signed by Keystone. Each part of token would include the service endpoints and user roles on that service. The part for target service S will include all roles the user has on this service. Keystone will check user grants for service S on other services, in this case T, and include the delegated roles in the part of token for service T. Each part is encrypted with a designated key of a service account in Keystone. Then, keystone signs the part as an issuer of token. Optionally, the entire token can be signed by Keystone. This encrypted and signed token is then returned to the user.

The user passes the token to the service S, which in turn validates the issuer’s signature and decrypts a part of token for its service ID. When service S needs to access user’s resources on service T it extracts a part of token for service T and includes it in a request. This part has a form of an independent token. Service T validates an issuer signature and decrypts the user roles in the token with its own key and executes the request.

When a malicious service S attempts to access user resources on service X and passes the token or its parts to X the service X will reject the request since the token is scoped for service S a it does not contain any roles or endpoint on service X. In fact, service X is only able to validate issuer’s signature but it will not be able to decrypt any part of this token.

To allow for periodical token revocation checks, Keystone will need to expose a Token Revocation API which allows service to check if the signed token has been revoked prior to its expiration time.