RBAC for Quantumhttp://etherpad.openstack.org/QuantumRBAC Tuesday, October 4 12.00 PM Openstack “Essex” design summitBoston – October 3-5 2001 Netstack track
Agenda Current status RBAC use cases Outcome from Keystone RBAC session Open discussion
Current status No Authentication/No Authorization Unofficially: Authentication provided by Keystone Simple Authorization performed with data returned by Keystone Issue: AuthZ requires expressing predicates on resources outside Quantum boundaries E.g.: the VIF, which is managed by Nova
Relevant Use Cases for RBAC Public and ‘community’ networks Networks which are owned by a specific tenant, but are accessible to other tenants as well Distinct roles within tenants Standard user / network administrator ‘Service’ resources Some interfaces might belong to services which are inserted by the Cloud Service Provider Recalls yesterday’s discussion Something missing?
Public/Community networks Definition: A network on which several tenants can plug their own interfaces, but is nevertheless always ‘owned’ by a single tenant Implementation: Simple way: the service provider acts as a tenant Single public network per deployment Bit more complex way: service provider defines and own several ‘public networks’ E.g.: each network has different QoS/security attributes Even more complex way: tenants can delegate access to their network to other tenants
Multiple roles within tenants A tenant can define several users Keystone already allows this Users are not all equals Keystone uses roles for handling this Introducing user roles in Quantum: Associating roles with base and extended operations ‘Fixed’ roles Fully customizable roles
Authorizing ‘Service’ interfaces Use case highlighted in Edgar’s session on Monday