Orchestration authorization model defines the process of authorization that orchestration module uses to authorize requests during so called deferred operations. The typical example of such operation is autoscaling group update when heat requests another components (nova, neutron or others) to extend (reduce) capacity of autoscaling group. At the current moment, Orchestration provides two kinds of authorization models: Password authorization. Authorization with OpenStack Identity trusts.

Password authorization is the initial authorization model that was supported by Orchestration module. This kind of authorization requires from a user to pass a password to Orchestration. Orchestration stores the encrypted password in database and uses it for deferred operations. The following steps are executed for password authorization: User requests stack creation, providing a token and username/password (python-heatclient or OpenStack dashboard normally requests the token for you). If the stack contains any resources marked as requiring deferred operations orchestration engine will fail validation checks if no username/password is provided. The username/password are encrypted and stored in the orchestration DB. Stack creation is completed. At some later stage Orchestration retrieves the credentials and requests another token on behalf of the user, the token is not limited in scope and provides access to all roles of the stack owner.

OpenStack Identity trusts is the new authorization method available since IceHouse release. Trusts are an OpenStack Identity extension, which provide a method to enable delegation, and optionally impersonation via OpenStack Identity. The key terminology is trustor (the user delegating) and trustee (the user being delegated to). To create a trust, the trustor(in this case the user creating the stack in Orchestration module) provides OpenStack Identity with the following information: The ID of the trustee(who you want to delegate to, in this case the Orchestration service user). The roles to be delegated(configurable via the heat.conf, but it needs to contain whatever roles are required to perform the deferred operations on the users behalf, e.g launching a OpenStack Compute instance in response to an AutoScaling event). Whether to enable impersonation. OpenStack Identity then provides a trust_id, which can be consumed by the trustee (and only the trustee) to obtain a trust scoped token. This token is limited in scope such that the trustee has limited access to those roles delegated, along with effective impersonation of the trustor user, if it was selected when creating the trust. More information is available in Identity management section. The following steps are executed for trusts authorization: User creates a stack via an API request (only the token is required). Orchestration uses the token to create a trust between the stack owner (trustor) and the heat service user (trustee), delegating a special role (or roles) as defined in the trusts_delegated_roles list in the heat configuration file. By default heat sets all roles from trustor available for trustee. Deployers may modify this list to reflect local RBAC policy, e.g to ensure the heat process can only access those services expected while impersonating a stack owner. Orchestration stores the encrypted trust id in the Orchestration DB. When a deferred operation is required, Orchestration retrieves the trust id, and requests a trust scoped token which enables the service user to impersonate the stack owner for the duration of the deferred operation, e.g to launch some OpenStack Compute instances on behalf of the stack owner in response to an AutoScaling event.

Password authorization model had been the default authorization model enabled for Orchestration module before Kilo release. Since Kilo release trusts authorization model has been enabled by default. To enable password authorization model the following change should be made in heat.conf: deferred_auth_method=password To enable trusts authorization model the following change should be made in heat.conf: deferred_auth_method=trusts To specify trustor roles that will be delegated to trustee during authorization trusts_delegated_roles parameter should be specified in heat.conf. If trusts_delegated_roles is not defined then all trustor roles will be delegated to trustee. Please pay attention that trust delegated roles should be pre-configured in OpenStack Identity before using it in Orchestration module.