1 / 23

Towards a Centralized Identity and Access Management for Telco Private Cloud

Explore the need for a centralized Identity and Access Management (IAM) solution for Telco Private Cloud, discussing requirements, challenges, and potential approaches.

rsherman
Download Presentation

Towards a Centralized Identity and Access Management for Telco Private Cloud

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Towards a Centralized Identity and Access Management for Telco Private Cloud Marc Bailly, marc1.bailly@orange.com Ruan He, ruanhe@tencent.com Bertrand Rault, brault@redhat.com

  2. Agenda Use cases (Requirements vs. OpenStack) Suggested approach: A centralized IAM

  3. Telco Private Cloud Context Telco Private Cloud = Multiple Datacenters • Geographically distributed Each Datacenter is a complete OpenStack Deployment instance • Instances are independent and autonomous. • Instances have their own Keystone database. • Instances do not rely on Keystone federation. • Instances have independent user authorization life cycle SDN Controller generally used in combination with OpenStack

  4. Identity and Access Management (IAM) for Telco Private Cloud Standard deployment does not allow to centralize the authorization. Synchronization of user accounts and associated permissions among these geographically distributed OpenStacks is a technical challenge. • • different instances? • SDN Controller RBAC? Consistent assignments of privileges / roles to a given user? Consistent management of roles and associated policies on the Internal / external source for Authentication How to behave when multi-DCs Consistent management between OpenStack and DC #1 Keystone Internal source for Authorizations Too few roles for Authorizations roles

  5. Identity and Access Management Requirements R1: Centralization of authentication R2: Centralization of role assignment R3: Centralization of policy management R4: Consistent authorization handling between OpenStack and external SDN Controller

  6. R1 - Centralization of Authentication Supported in OpenStack today • directories • domains • Through integration with existing LDAP Keystone DC #1 users Used in combination with OpenStack CentralizedL DAP Through Keystone to Keystone federation users Keystone DC #n

  7. R2 - Centralization of Role Assignment Not easily handled in OpenStack today • assigned to users Keystone has its own local database to store roles Keystone DC #1 Roles users The way we handle it today • • to a same user on projects deployed on the different OpenStack instances CentralizedL DAP Assignment of Role to users Usage of an external assignment system Assign & maintain in each Keystone the same role users Roles Keystone DC #n

  8. R3 – Centralization of Policy Assignment Today we have only local policy enforcement • Performed independently by each OpenStack service for each OpenStack instance leveraging oslo_policy engine DC #1 Keystone Policy file Policy file roles users … Based on rules defined in policy file • Centralized LDAP Policy authorization assignment One policy file per service. Minimum set of roles out of the box • No sufficient for Telco Use case • users roles Keystone … Policy file DC #n Policy file

  9. Policy File Format Structure review • A set of definitions alias:definition • A set of rules target:rule Where: A target represents the action to be performed and A rule is a set of check to be performed

  10. Policy File Format Example "infra_operator": "role:infra_operator", "project_operator": "(project_id:%(project_id)s and role:project_operator)", "member": "(project_id:%(project_id)s and rule:_member_role)", "readonly": "(project_id:%(project_id)s and role:readonly)", "admin": "(is_admin:True or role:admin)", … "os_compute_api:os-extended-server-attributes": "rule:admin_or_member_or_readonly_or_operator", "os_compute_api:os-instance-usage-audit-log": "rule:admin", "os_compute_api:os-consoles:delete": "rule:admin_or_member_or_operator", "os_compute_api:os-networks": "rule:admin or rule:infra_operator", …

  11. Defining a read only rule within a policy file The following definition and rule will allow a user with the readonly role to list instances • "readonly": "(project_id:%(project_id)s and role:readonly)", "os_compute_api:servers:show": "rule:admin or rule:member or rule:readonly",  Where the project_id of the authenticated user will be compared with the project_id of the resource being access  And the authenticated user has the readonly role.  The rule checks that only user with admin or member or readonly can list instances.

  12. Managing and Defining rules is daunting tasks Those rules are not always easy to understand. Those rules are not always flexible to configure. Policy update may require to touch each policy file for each service for each OpenStack instance in each datacenter. Prone to error leading to unexpected side effects and security compliance violation.

  13. R4 - Consistent authorization handling between OpenStack and external SDN Controller Not fulfilled by OpenStack and SDN Controller today The way we handle it today: • authorization with its own RBAC system complementing OpenStack RBAC DC #1 SDN Controller Each SDN Controller handles its own Keystone Policy file Policy file roles users … Centralized LDAP Role and policy authorization assignment External assignment system configure • and maintain consistency across the multiple SDN Controllers. users roles Keystone … Policy file Policy file SDN Controller DC #n

  14. Alternative is an External Policy Decision Point, aka External PDP Delegate the authorizations • • Still Multiple independent OpenStack deployments. Yet Single policy decision point.

  15. A Common data-model for policy specification heterogeneous security models evolutionary execution context various levels in virtual architecture   

  16. Policy chaining to integrate multiple aspects How to integrate heterogeneous security requirements of different aspects? Administrator End-user Security Policy Mgt Interfaces Security Policy Mgt Interfaces different kinds of implied users work on different aspects modify simultaneously one security policy enforced by the same PDP/enforcer     … Deployer Security Policy Mgt Interfaces Security Policy#1 Security Policy#2 Security Policy#n … Security Policy

  17. OPNVF Moon External PDP – Technical view Moon is based on • Microservice approach with Docker and Kubernetes • Master/ slave architecture • master manages the data • slaves handles authorization requests • slaves retrieve information from the master when needed • master sends a updates to slaves when data has been changed Moon applies • 1 policy per 1 tenant is through 1 Kubernetes pods • pods can be manually and/or automatically (un)loaded

  18. External PDP – Security Concerns High Availability • K8S pods management allow the dynamic scalability Denial of Service  because the External PDP is a standalone server  → access to the External PDP interfaces must be secured  → master/slave architecture allows to mitigate the risk (an insider cannot attack the whole system) Man in the Middle • because External PDP interacts with OpenStack platform, an intruder can intercept messages between them • → internal connections are secured • → network connecting OpenStack and External PDP must be secured

  19. A Generic External PDP Hook in OpenStack Hook is based on a new private function in oslo_policy._checks Allow to redirect authorization requests to an External PDP Allow users to choose between local policy or an External PDP Was a Join effort between Orange, Red Hat and Upstream community.  Spec proposed in August 2017  Spec merged in September 2017  Code merged in September 2017

  20. Using the External PDP Hook: What does our rule look like? Policy.json before External PDP Hook implementation: • "readonly": "(project_id:%(project_id)s and role:readonly)", "os_compute_api:servers:show": "rule:admin or rule:member or rule:readonly", Policy.json after External PDP Hook implementation: • "os_compute_api:servers:show": http://url-to-external-pdp:port/

  21. In summary: Telco Private Clouds have unique requirements not adequately met today Different approaches considered in term of policy authorization - • Role assignments to users performed in each Keystone instance. • - • Role assignments to users performed once in PDP. • - Other Approach… 1st Approach: Perform configuration synchronization Roles defined in each Keystone instance. • Policy assignments performed in each Keystone instance. 2nd Approach: Centralize the configuration to an external PDP Roles defined once in the PDP. • Policy assignments is done once in the PDP.

  22. References Moon Project • Git: https://git.opnfv.org/moon/tree/README.md Wiki: https://wiki.opnfv.org/display/moon/Moon • External PDP Hook • Upstream Spec (Oslo.policybased): https://review.openstack.org/#/c/492543/ • Blueprint: https://blueprints.launchpad.net/keystone/+spec/external-pdp-for-keystone • Upstream Code (Oslo.policy based): https://review.openstack.org/#/c/498467/ OpenDaylight • Upstream Code (OpenDaylight based): https://git.opendaylight.org/gerrit/#/c/66615/

  23. Thank You for listening! Q&A

More Related