Confluent Platform Security Components
Die Bereitstellung und der Betrieb eines verteilten und skalierbaren Datensystems kann eine Herausforderung darstellen. Wenn die Plattform skaliert wird, um zusätzliche Use Cases zu unterstützen, stehen Unternehmen vor Herausforderungen wie langen Bereitstellungszyklen, betrieblicher Komplexität oder Schwierigkeiten bei der Gewährleistung von Security auf Unternehmensebene.Eine umfassende Sicherheitsstrategie beinhaltet die Sicherstellung des Zugriffs auf Ressourcen auf eine Weise, die einfach genug zu begründen ist, aber dennoch flexibel genug, um die Sicherheitsrichtlinien Ihres Unternehmens präzise umzusetzen. Wenn die Nutzung von Event Streaming zunimmt, müssen Sie möglicherweise Dutzenden oder sogar Hunderten von Benutzern/Service-Accounts Zugriff gewähren. Dazu gehören nicht nur Kafka, sondern auch Connect, KSQL, Schema Registry usw., und es erfordert eine neue Denkweise über die Autorisierung.In diesem Webinar stellen wir die neuen Security-Komponenten (Role Based Access Control -RBAC und Secret Protection) von Confluent Platform live vor und gehen auch auf die Best Practices in diesem Umfeld ein.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Confluent Platform Security Components
Similar to Confluent Platform Security Components (20)
More from confluent
More from confluent (20)
Recently uploaded
Recently uploaded (20)
Confluent Platform Security Components
- 1. 1C O N F I D E N T I A L Confluent Platform Security Components Suvad Sahovic suvad@confluent.io
- 2. 2C O N F I D E N T I A L RBAC
- 3. 3C O N F I D E N T I A L Challenges #1
- 4. 4C O N F I D E N T I A L C3 KSQL REST Proxy SR CONN. Challenges #2
- 5. 5C O N F I D E N T I A L C3 KSQL REST Proxy SR CONN.
- 6. 6C O N F I D E N T I A L 6 Managing Role Binding Role Binding Users/groups Roles ● Privileged users can setup, view and manage roles for others ● This includes both users and groups ● User/Group information is integrated with AD/LDAP ● In preview, the management of roles is done through the new CLI Resource scoping 5.3 Release
- 7. 7C O N F I D E N T I A L 7 Enforcing Authorization CLIGUI API RBAC authorization ● User access to the platform is authorized based on their role ● Enforcement is done across all user interfaces: CLI, Control Center (GUI), and APIs ● RBAC works with Apache Kafka ACLs Role Binding 5.3 Release
- 8. 8C O N F I D E N T I A L 8 RBAC RBAC Predefined roles Developer SystemAdmin UserAdminsuper.user ClusterAdminResourceOwner Operator SecurityAdmin Available now
- 9. 9C O N F I D E N T I A L D E M O
- 10. 10
- 11. 11 RBAC role binding ./confluent iam rolebinding create --principal Group:m3ddev --role DeveloperWrite --resource Connector:m3d-connector- --prefix --kafka-cluster-id OGpC-FNLTV6MHVOM8ZDj5g --connect-cluster-id connect-cluster
Editor's Notes
- RBAC in CP consists of roles, rolebindings, and principals A role has a set of allowed operations on certain CP resources A principal is a user or group A rolebinding is a mapping or statement saying that a certain principal has a certain role Rolebindings always are defined in a particular scope and can be talking about a cluster or a resource within a cluster Example rolebinding: “User Bob has the ClusterAdmin role on Kafka cluster my-test-cluster” Key RBAC operations: Create rolebindings. List rolebindings. Delete rolebindings. List available roles and their associated access policies. (Internal to CP) enforce rolebindings. Other highlights: We will utilize a predefined set of Roles: SystemAdmin, ClusterAdmin, Operator, UserAdmin, ResourceOwner, Developer, SecurityAdmin. A user who is assigned a role receives all the privileges of that role. Each user could belong to multiple roles. A privileged user within a given scope can create/update another user’s roles: { user, role, scope } Privileged user can update the roles for existing users (add/revoke roles). Centralized AD/LDAP setup for authentication and authorization.
- SystemAdmin Full Access to all resources UserAdmin Manages Users, Groups and Roles Operator Has access to application health & monitoring. Can restart applications, but cannot edit them ResourceOwner Owns a set of resources (schemas, topics, consumer groups, applications, etc.) and can grant permissions to those resources, but cannot change topic setups ClusterAdmin Manages clusters & brokers. Can create and edit topics but cannot read/write into them Developer Can create applications and change queries SecurityAdmin Manages audit logs and other security settings