diff --git a/local-antora-playbook.yml b/local-antora-playbook.yml index d8d478c82..83499f2ba 100644 --- a/local-antora-playbook.yml +++ b/local-antora-playbook.yml @@ -15,7 +15,7 @@ content: - url: . branches: HEAD - url: https://github.com/redpanda-data/documentation - branches: [main, v/*, shared, site-search] + branches: [DOC-1809-remove-register-groups-from-gbac-dp, v/*, shared, site-search] - url: https://github.com/redpanda-data/docs-site branches: [main] start_paths: [home] diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index e4f4969b1..29268c171 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -533,6 +533,9 @@ *** xref:security:authorization/rbac/index.adoc[Role-Based Access Control (RBAC)] **** xref:security:authorization/rbac/rbac.adoc[] **** xref:security:authorization/rbac/rbac_dp.adoc[] +*** xref:security:authorization/gbac/index.adoc[Group-Based Access Control (GBAC)] +**** xref:security:authorization/gbac/gbac.adoc[] +**** xref:security:authorization/gbac/gbac_dp.adoc[] *** xref:security:authorization/rbac/acl.adoc[Access Control Lists (ACLs)] *** xref:security:authorization/cloud-iam-policies.adoc[] *** xref:security:authorization/cloud-iam-policies-gcp.adoc[] diff --git a/modules/ai-agents/partials/service-account-authorization.adoc b/modules/ai-agents/partials/service-account-authorization.adoc index b871009d5..206a6e776 100644 --- a/modules/ai-agents/partials/service-account-authorization.adoc +++ b/modules/ai-agents/partials/service-account-authorization.adoc @@ -53,4 +53,4 @@ The default Writer role provides broad access suitable for most use cases. If yo . Find the service account for your resource. . Edit the role bindings to use a more restrictive role or scope. -For more information about roles and permissions, see xref:security:authorization/rbac/rbac.adoc[Role-based access control]. +For more information about roles and permissions, see xref:security:authorization/rbac/rbac.adoc[Role-based access control] or xref:security:authorization/gbac/gbac.adoc[Group-based access control]. diff --git a/modules/billing/pages/billing-notifications.adoc b/modules/billing/pages/billing-notifications.adoc index 9566dad04..1cb8257cf 100644 --- a/modules/billing/pages/billing-notifications.adoc +++ b/modules/billing/pages/billing-notifications.adoc @@ -37,7 +37,7 @@ Notifications are sent to email only. The subject line follows this format: == Who receives notifications -All users with the *Admin* role in your organization receive billing notifications by default. To change who receives notifications, update role assignments on the *Organization IAM* page. See xref:security:authorization/rbac/rbac.adoc[Role-Based Access Control]. +All users with the *Admin* role in your organization receive billing notifications by default. To change who receives notifications, update role assignments on the *Organization IAM* page. See xref:security:authorization/rbac/rbac.adoc[Role-Based Access Control] or xref:security:authorization/gbac/gbac.adoc[Group-Based Access Control]. == Opt out of notifications diff --git a/modules/get-started/pages/byoc-arch.adoc b/modules/get-started/pages/byoc-arch.adoc index 2f351161c..2a1dd7a8f 100644 --- a/modules/get-started/pages/byoc-arch.adoc +++ b/modules/get-started/pages/byoc-arch.adoc @@ -9,9 +9,9 @@ For high availability, Redpanda Cloud uses the following control plane - data pl image::shared:control_d_plane.png[Control plane and data plane] -* *Control plane*: This is a Redpanda Cloud managed service that manages provisioning, operations, and maintenance of clusters with Kubernetes under the hood, including Kubernetes version upgrades and infrastructure maintenance. The control plane enforces rules in the data plane. You can use role-based access control xref:security:authorization/rbac/rbac.adoc[(RBAC) in the control plane] to manage access to organization-level resources like clusters, resource groups, and networks. +* *Control plane*: This is a Redpanda Cloud managed service that manages provisioning, operations, and maintenance of clusters with Kubernetes under the hood, including Kubernetes version upgrades and infrastructure maintenance. The control plane enforces rules in the data plane. You can use xref:security:authorization/rbac/rbac.adoc[RBAC] or xref:security:authorization/gbac/gbac.adoc[GBAC] in the control plane to manage access to organization-level resources like clusters, resource groups, and networks. -* *Data plane*: This is where your cluster lives. The term _data plane_ is sometimes used interchangeably with _cluster_. The data plane is where you manage topics, consumer groups, connectors, and schemas. You can use xref:security:authorization/rbac/rbac_dp.adoc[RBAC in the data plane] to configure cluster-level permissions for provisioned users at scale. +* *Data plane*: This is where your cluster lives. The term _data plane_ is sometimes used interchangeably with _cluster_. The data plane is where you manage topics, consumer groups, connectors, and schemas. You can use xref:security:authorization/rbac/rbac_dp.adoc[RBAC] or xref:security:authorization/gbac/gbac_dp.adoc[GBAC] in the data plane to configure cluster-level permissions for provisioned users at scale. IAM permissions allow the Redpanda Cloud agent to access the cloud provider API to create and manage cluster resources. The permissions follow the principle of least privilege, limiting access to only what is necessary. diff --git a/modules/get-started/pages/cloud-overview.adoc b/modules/get-started/pages/cloud-overview.adoc index 2d806819c..776ee065d 100644 --- a/modules/get-started/pages/cloud-overview.adoc +++ b/modules/get-started/pages/cloud-overview.adoc @@ -91,7 +91,12 @@ Redpanda Cloud applications are supported by three fully-managed deployment opti | ✓ | ✓ -| *RBAC & audit logs* +| *Role-based access control (RBAC) & audit logs* +| ✗ +| ✓ +| ✓ + +| *Group-based access control (GBAC)* | ✗ | ✓ | ✓ @@ -200,6 +205,7 @@ Consider BYOC or Dedicated if you need more control over the deployment or if yo * Redpanda Agentic Data Plane (ADP): BYOC only * Multiple availability zones (AZs). A multi-AZ cluster provides higher resiliency in the event of a failure in one of the zones. * Role-based access control (RBAC) in the data plane +* Group-based access control (GBAC) * Kafka Connect * Higher limits and quotas. See xref:reference:tiers/byoc-tiers.adoc[BYOC usage tiers] and xref:reference:tiers/dedicated-tiers.adoc[Dedicated usage tiers] compared to xref:get-started:cluster-types/serverless.adoc#serverless-usage-limits[Serverless limits]. diff --git a/modules/get-started/pages/cluster-types/serverless.adoc b/modules/get-started/pages/cluster-types/serverless.adoc index a1922162e..e53c26e5b 100644 --- a/modules/get-started/pages/cluster-types/serverless.adoc +++ b/modules/get-started/pages/cluster-types/serverless.adoc @@ -100,7 +100,8 @@ Not all features included in BYOC clusters are available in Serverless. For exam * HTTP Proxy API * Multiple availability zones (AZs) -* RBAC in the data plane and mTLS authentication for Kafka API clients +* Role-based access control (RBAC) in the data plane and mTLS authentication for Kafka API clients +* Group-based access control (GBAC) * Kafka Connect == Next steps diff --git a/modules/get-started/pages/whats-new-cloud.adoc b/modules/get-started/pages/whats-new-cloud.adoc index 820ecb688..422f65609 100644 --- a/modules/get-started/pages/whats-new-cloud.adoc +++ b/modules/get-started/pages/whats-new-cloud.adoc @@ -6,6 +6,14 @@ This page lists new features added to Redpanda Cloud. +== April 2026 + +=== Group-based access control (GBAC) + +With xref:security:authorization/gbac/gbac.adoc[GBAC in the control plane], you can manage access to organization-level resources using OIDC groups from your identity provider. Assign OIDC groups to roles so that users inherit access based on their group membership. + +With xref:security:authorization/gbac/gbac_dp.adoc[GBAC in the data plane], you can configure cluster-level permissions for provisioned users at scale using OIDC groups. Because group membership is managed by your identity provider, onboarding and offboarding require no changes in Redpanda. GBAC is available for BYOC and Dedicated clusters. + == March 2026 === Redpanda Connect updates diff --git a/modules/security/pages/authorization/cloud-authorization.adoc b/modules/security/pages/authorization/cloud-authorization.adoc index 7651da652..1bfa131d0 100644 --- a/modules/security/pages/authorization/cloud-authorization.adoc +++ b/modules/security/pages/authorization/cloud-authorization.adoc @@ -7,6 +7,7 @@ There are two types of authorization in Redpanda Cloud: * User authorization + ** Use xref:security:authorization/rbac/index.adoc[role-based access control (RBAC)] in the glossterm:control plane[] and in the glossterm:data plane[] to assign users access to specific resources. For example, you could grant everyone access to clusters in a development resource group while limiting access to clusters in a production resource group. Or, you could limit access to geographically-dispersed clusters in accordance with data residency laws. This alleviates the process of manually maintaining and verifying a set of ACLs for a user base that may contain thousands of users. +** Use xref:security:authorization/gbac/index.adoc[group-based access control (GBAC)] in the glossterm:control plane[] and in the glossterm:data plane[] to manage permissions at the group level using OIDC. Assign OIDC groups to roles or create ACLs with `Group:` principals, so that users inherit access based on their group membership in your identity provider. Because group membership is managed by your identity provider, onboarding and offboarding require no changes in Redpanda. ** Use Kafka glossterm:ACL[,access control lists (ACLs)] to grant users permission to perform specific types of operations on specific resources (such as topics, groups, clusters, or transactional IDs). ACLs provide a way to configure fine-grained access to provisioned users. ACLs work with SASL/SCRAM and with mTLS with principal mapping for authentication. * BYOC agent authorization diff --git a/modules/security/pages/authorization/gbac/gbac.adoc b/modules/security/pages/authorization/gbac/gbac.adoc new file mode 100644 index 000000000..29e4ce2d2 --- /dev/null +++ b/modules/security/pages/authorization/gbac/gbac.adoc @@ -0,0 +1,101 @@ += Configure GBAC in the Control Plane +:description: Configure GBAC to manage access to organization-level resources, like clusters, resource groups, and networks, using OIDC groups from your identity provider. +:page-topic-type: how-to +:learning-objective-1: Register an OIDC group in Redpanda Cloud +:learning-objective-2: Assign a predefined or custom role to a group +:learning-objective-3: Manage group-based access at the organization level + +NOTE: This feature is available for BYOC and Dedicated clusters. + +Use Redpanda Cloud group-based access control (GBAC) in the glossterm:control plane[] to manage and restrict access to resources in your organization using OIDC groups from your identity provider. For example, you could grant everyone in a group access to clusters in a development resource group while limiting access to clusters in a production resource group. Or, you could limit access to geographically-dispersed clusters in accordance with data residency laws. + +After reading this page, you will be able to: + +* [ ] {learning-objective-1} +* [ ] {learning-objective-2} +* [ ] {learning-objective-3} + +The following resources can be assigned as the scope of a role: + +- Organization +- Resource groups +- Networks +- Network peerings +- Clusters (Serverless clusters have a different set of permissions from BYOC and Dedicated clusters.) +- Topics +- MCP servers +- AI agents +- AI gateway +- AI Gateway models +- AI Gateway model providers +- AI Gateway config + +You can manage these GBAC configurations with the https://cloud.redpanda.com[Redpanda Cloud Console^] or with the link:/api/doc/cloud-controlplane/[Control Plane API]. + +== GBAC terminology + +**Group**: A group is a collection of users defined in your identity provider. With GBAC, you can assign groups to roles or ACLs in Redpanda Cloud, so that users inherit permissions based on their group membership in your identity provider. + +**Role**: A role is a list of permissions. Permissions are attached to roles. Users assigned multiple roles receive the union of all permissions defined in those roles. Redpanda Cloud has three predefined roles: Reader, Writer, and Admin, but you can also create custom roles. + +**Role binding**: Role binding assigns a role to an account. + +== Manage access for organization + +In the Redpanda Cloud Console, the *Organization IAM* page lets you create groups, edit a user's access, invite new users, and create service accounts. + +== Register groups in Redpanda Cloud + +To assign an IdP group to a role or ACL, you must first register the group: + +[tabs] +==== +Cloud UI:: ++ +-- +. In the left navigation menu, select *Organization IAM*, then select the *Groups* tab. +. Click *Create group*. +. Enter a *Name* that matches the group in your IdP exactly (for example, `engineering`). +. Optionally, enter a *Description*, and configure a *Role binding* to assign the group to a role with a specific scope and resource. +. Click *Create*. +-- + +Control Plane API:: ++ +-- +Make a link:/api/doc/cloud-controlplane/operation/operation-groupservice_creategroup[`POST /v1/groups`] request to the xref:redpanda-cloud:manage:api/cloud-byoc-controlplane-api.adoc[Control Plane API]: + +[,bash] +---- +curl -X POST 'https://api.redpanda.com/v1/groups' \ + -H 'Content-Type: application/json' \ + -H 'Authorization: Bearer ' \ + -d '{ + "group": { + "name": "", + "description": "" + } + }' +---- + +Replace `` with the name that matches the group in your IdP (for example, `engineering`). The name must match exactly for GBAC to map the group correctly. +-- +==== + +== Predefined roles + +include::security:partial$predefined-roles.adoc[] + +== Custom roles + +In addition to the predefined roles, administrators can create custom roles to mix and match permissions for specific use cases. Custom roles let you grant only the permissions a group needs, without the broad access of the predefined Reader, Writer, or Admin roles. + +Custom roles are created on the *Roles* tab in *Organization IAM*. For steps to create a custom role, see xref:security:authorization/rbac/rbac.adoc#custom-roles[Custom roles in RBAC]. + +When you register a group or edit a group's role binding, you can assign any predefined or custom role to the group. + +== Suggested reading + +* xref:security:authorization/gbac/gbac_dp.adoc[] +* xref:security:authorization/rbac/rbac.adoc[] +* xref:security:authorization/rbac/rbac_dp.adoc[] diff --git a/modules/security/pages/authorization/gbac/gbac_dp.adoc b/modules/security/pages/authorization/gbac/gbac_dp.adoc new file mode 100644 index 000000000..3bbdb7ff4 --- /dev/null +++ b/modules/security/pages/authorization/gbac/gbac_dp.adoc @@ -0,0 +1,17 @@ += Configure GBAC in the Data Plane +:description: Configure GBAC to manage access for provisioned users to cluster-level resources, like topics and consumer groups, using OIDC groups from your identity provider. +:learning-objective-1: Configure the cluster properties that enable GBAC +:learning-objective-2: Assign an OIDC group to an RBAC role +:learning-objective-3: Create a group-based ACL using the Group: principal prefix + +NOTE: This feature is available for BYOC and Dedicated clusters. + +Use group-based access control (GBAC) in the glossterm:data plane[] to configure cluster-level permissions for provisioned users at scale. GBAC works in conjunction with all supported authentication methods. + +include::ROOT:manage:partial$gbac-dp.adoc[tag=single-source] + +== Suggested reading + +* xref:security:authorization/gbac/gbac.adoc[] +* xref:security:authorization/rbac/rbac.adoc[] +* xref:security:authorization/rbac/rbac_dp.adoc[] diff --git a/modules/security/pages/authorization/gbac/index.adoc b/modules/security/pages/authorization/gbac/index.adoc new file mode 100644 index 000000000..e495acf6f --- /dev/null +++ b/modules/security/pages/authorization/gbac/index.adoc @@ -0,0 +1,3 @@ += Group-Based Access Control (GBAC) +:description: Learn about configuring group-based access control (GBAC) in the control plane and in the data plane. +:page-layout: index diff --git a/modules/security/pages/authorization/rbac/rbac.adoc b/modules/security/pages/authorization/rbac/rbac.adoc index 98551c2d7..23e3b6f88 100644 --- a/modules/security/pages/authorization/rbac/rbac.adoc +++ b/modules/security/pages/authorization/rbac/rbac.adoc @@ -1,9 +1,21 @@ = Configure RBAC in the Control Plane :description: Configure RBAC to manage access to organization-level resources like clusters, resource groups, and networks. +:page-topic-type: how-to +:learning-objective-1: Assign predefined or custom roles to users and service accounts +:learning-objective-2: Manage role bindings at the organization level +:learning-objective-3: Create custom roles with granular permissions -Use Redpanda Cloud role-based access control (RBAC) in the glossterm:control plane[] to manage and restrict access to resources in your organization. For example, you could grant everyone in your organization access to clusters in a development resource group while limiting access to clusters in a production resource group. Or, you could limit access to geographically-dispersed clusters in accordance with data residency laws. +NOTE: This feature is available for BYOC and Dedicated clusters. -The following resources can be assigned as the scope of a role: +Use Redpanda Cloud role-based access control (RBAC) in the glossterm:control plane[] to manage and restrict access to resources in your organization. For example, you could grant everyone in a group access to clusters in a development resource group while limiting access to clusters in a production resource group. Or, you could limit access to geographically-dispersed clusters in accordance with data residency laws. + +After reading this page, you will be able to: + +* [ ] {learning-objective-1} +* [ ] {learning-objective-2} +* [ ] {learning-objective-3} + +Various resources can be assigned as the scope of a role. For example: - Organization - Resource groups @@ -11,13 +23,13 @@ The following resources can be assigned as the scope of a role: - Network peerings - Clusters (Serverless clusters have a different set of permissions from BYOC and Dedicated clusters.) -NOTE: Topics are not included. For topic-level access control, see xref:security:authorization/rbac/rbac_dp[Configure RBAC in the Data Plane]. +NOTE: Redpanda topics are not included. For topic-level access control, see xref:security:authorization/rbac/rbac_dp[Configure RBAC in the Data Plane]. -You can manage these RBAC configurations with the https://cloud.redpanda.com[Redpanda Cloud UI^] or with the link:/api/doc/cloud-controlplane/[Control Plane API]. +You can manage these RBAC configurations with the https://cloud.redpanda.com[Redpanda Cloud Console^] or with the link:/api/doc/cloud-controlplane/[Control Plane API]. == RBAC terminology -**Role**: A role is a list of permissions. With RBAC, permissions are attached to roles. Users assigned multiple roles receive the union of all permissions defined in those roles. Redpanda Cloud has three predefined roles: Reader, Writer, and Admin. +**Role**: A role is a list of permissions. With RBAC, permissions are attached to roles. Users assigned multiple roles receive the union of all permissions defined in those roles. Redpanda Cloud has three predefined roles: Reader, Writer, and Admin, but you can also create custom roles. **Account**: An RBAC account is either a user account (human user) or a service account (machine or programmatic user). @@ -25,7 +37,7 @@ You can manage these RBAC configurations with the https://cloud.redpanda.com[Red == Manage access for organization -In the Redpanda Cloud UI, the *Organization IAM* page lists your organization's existing users and service accounts and their associated roles. You can edit a user's access, invite new users, and create service accounts. When you add a user, you define their permissions with role binding. Service accounts are assigned the Admin role for all resources in the organization. +In the Redpanda Cloud Console, the *Organization IAM* page lists your organization's existing users and service accounts and their associated roles. You can edit a user's access, invite new users, and create service accounts. When you add a user, you define their permissions with role binding. Service accounts are assigned the Admin role for all resources in the organization. On the *Organization IAM - Users* page, select a user to see their assigned roles. For example, for a user with Admin access on the organization, the user's _Resource_ is the organization name, the _Scope_ is organization, and the _Role_ is Admin. @@ -37,32 +49,26 @@ When you delete a role, Redpanda removes it from any user or service account it == Predefined roles -Redpanda Cloud provides the following predefined roles: <>, <>, and <>. - -=== Reader +include::security:partial$predefined-roles.adoc[] -The Reader role grants permission to view all resources. This includes: +== Custom roles -* View all networks and clusters (Serverless, BYOC, and Dedicated). -* View all cluster aspects (ACLs, service accounts, quotas). -* View all topic aspects (messages, configs, partitions, using search filters). -* View all consumer group aspects (consumer groups, group offsets, and lags). -* View all schema registry aspects (registered schemas with their contents). -* View all Kafka Connect aspects (list configured clusters and their connectors, including the status and connector configurations). -* This does not include permission to view the list of users. +In addition to the predefined roles, administrators can create custom roles to mix and match permissions for specific use cases. Custom roles let you grant only the permissions a user needs, without the broad access of the predefined Reader, Writer, or Admin roles. -=== Writer +To create a custom role, use the https://cloud.redpanda.com[Redpanda Cloud Console^] or the link:/api/doc/cloud-controlplane/[Control Plane API]. -The Writer role grants all permissions that come with the Reader role and additionally includes: +In the Redpanda Cloud Console: -* Manage all topic aspects, such as create topics, edit topic configurations, delete topics, and publish and delete topic records. -* Manage all consumer group aspects, such as edit group offsets and delete group offsets. -* Manage all Kafka Connect aspects, such as create/update/delete and start/pause/stop Kafka Connect. -* This does not include permission to create/remove ACLs and service accounts. +. In the left navigation menu, select *Organization IAM*, then select the *Roles* tab. +. Click *Create role*. +. Enter a *Name* and optional *Description* for the role. +. Select permissions from the available categories: *Control Plane*, *Data Plane*, *IAM*, and *Billing*. Each category contains multiple permission groups (for example, Cluster, Network, or Topic), and each group contains individual operations such as Create, Read, Update, and Delete. You can select operations individually or select all operations for a group. +. Click *Create*. -=== Admin +After creating a custom role, you can assign it to users through role bindings on the *Users* tab. -The Admin role grants all permissions that come with the Writer role and additionally includes: +== Suggested reading -* Manage all service account aspects (create/remove service accounts). -* Manage all ACL aspects (create/remove ACLs). \ No newline at end of file +* xref:security:authorization/rbac/rbac_dp.adoc[] +* xref:security:authorization/gbac/gbac.adoc[] +* xref:security:authorization/gbac/gbac_dp.adoc[] \ No newline at end of file diff --git a/modules/security/pages/authorization/rbac/rbac_dp.adoc b/modules/security/pages/authorization/rbac/rbac_dp.adoc index fc0c97117..1f3da4fc3 100644 --- a/modules/security/pages/authorization/rbac/rbac_dp.adoc +++ b/modules/security/pages/authorization/rbac/rbac_dp.adoc @@ -1,8 +1,24 @@ = Configure RBAC in the Data Plane :description: Configure RBAC to manage access for provisioned users to cluster-level resources, like topics and consumer groups. +:page-topic-type: how-to +:learning-objective-1: Configure cluster-level permissions for provisioned users +:learning-objective-2: Assign roles to users in the data plane +:learning-objective-3: Use RBAC with supported authentication methods -Use role-based access control (RBAC) in the glossterm:data plane[] to configure cluster-level permissions for provisioned users at scale. RBAC works in conjunction with all supported authentication methods. +NOTE: This feature is available for BYOC and Dedicated clusters. -RBAC in the data plane is available for BYOC and Dedicated clusters. +Use role-based access control (RBAC) in the glossterm:data plane[] to configure cluster-level permissions for provisioned users at scale. -include::ROOT:manage:partial$rbac-dp.adoc[tag=single-source] \ No newline at end of file +After reading this page, you will be able to: + +* [ ] {learning-objective-1} +* [ ] {learning-objective-2} +* [ ] {learning-objective-3} + +include::ROOT:manage:partial$rbac-dp.adoc[tag=single-source] + +== Suggested reading + +* xref:security:authorization/rbac/rbac.adoc[] +* xref:security:authorization/gbac/gbac.adoc[] +* xref:security:authorization/gbac/gbac_dp.adoc[] \ No newline at end of file diff --git a/modules/security/partials/predefined-roles.adoc b/modules/security/partials/predefined-roles.adoc new file mode 100644 index 000000000..f6de66d35 --- /dev/null +++ b/modules/security/partials/predefined-roles.adoc @@ -0,0 +1,29 @@ +Redpanda Cloud provides the following predefined roles: <>, <>, and <>. + +=== Reader + +The Reader role grants permission to view all resources. This includes: + +* View all networks and clusters (Serverless, BYOC, and Dedicated). +* View all cluster aspects (ACLs, service accounts, quotas). +* View all topic aspects (messages, configs, partitions, using search filters). +* View all consumer group aspects (consumer groups, group offsets, and lags). +* View all schema registry aspects (registered schemas with their contents). +* View all Kafka Connect aspects (list configured clusters and their connectors, including the status and connector configurations). +* This does not include permission to view the list of users. + +=== Writer + +The Writer role grants all permissions that come with the Reader role and additionally includes: + +* Manage all topic aspects, such as create topics, edit topic configurations, delete topics, and publish and delete topic records. +* Manage all consumer group aspects, such as edit group offsets and delete group offsets. +* Manage all Kafka Connect aspects, such as create/update/delete and start/pause/stop Kafka Connect. +* This does not include permission to create/remove ACLs and service accounts. + +=== Admin + +The Admin role grants all permissions that come with the Writer role and additionally includes: + +* Manage all service account aspects (create/remove service accounts). +* Manage all ACL aspects (create/remove ACLs).