Add role-based access control#8384
Draft
ramonsmits wants to merge 3 commits into
Draft
Conversation
Adds RBAC documentation for ServiceControl PR #5518 (6.18.0) and ServicePulse PR #3049 (2.9.0): - New ServiceControl authorization guide covering the permission model, built-in roles (reader/admin/writer), reading roles per identity provider, enabling authorization, and the authorization audit log - New ServicePulse authorization page covering permission-gated UI and the 'Your permissions' page - New Authentication.RoleBasedAuthorizationEnabled, RolesClaim, SubjectIdClaim and SubjectNameClaim settings on all three instances - Cross-links from security overviews and authentication pages - Menu entries under both security sections
Remove the permission-key model and manifest/routing plumbing that is not relevant to configuring an identity provider. Add a step-by-step 'How to enable role-based access control' section covering the required SC/SP versions, config keys, and IdP role setup.
WilliamBZA
approved these changes
Jul 2, 2026
dvdstelt
reviewed
Jul 6, 2026
| | `admin` | Everything `reader` can do, plus managing the configuration and administration areas (licensing, notifications, retry redirects, throughput, and connections). | | ||
| | `writer` | Full access, including message actions such as retry, edit, archive, and restore. | | ||
|
|
||
| Role names are matched case-insensitively. A user with none of these roles has no access to the affected areas. |
Member
There was a problem hiding this comment.
Suggested change
| Role names are matched case-insensitively. A user with none of these roles has no access to the affected areas. | |
| The roles are cumulative: `writer` is the highest level and can do everything `admin` and `reader` can, and `admin` can do everything `reader` can. Role names are matched case-insensitively, and a user with none of these roles has no access to the affected areas. |
|
|
||
| 5. Restart all ServiceControl instances. | ||
|
|
||
| Each instance authorizes its own requests, so all instances must have authorization enabled. For the app config keys and environment variables of every instance type, see [Primary](/servicecontrol/servicecontrol-instances/configuration.md#authentication), [Audit](/servicecontrol/audit-instances/configuration.md#authentication), and [Monitoring](/servicecontrol/monitoring-instances/configuration.md#authentication) configuration. |
Member
There was a problem hiding this comment.
Suggested change
| Each instance authorizes its own requests, so all instances must have authorization enabled. For the app config keys and environment variables of every instance type, see [Primary](/servicecontrol/servicecontrol-instances/configuration.md#authentication), [Audit](/servicecontrol/audit-instances/configuration.md#authentication), and [Monitoring](/servicecontrol/monitoring-instances/configuration.md#authentication) configuration. | |
| Each instance authorizes its own requests, so all instances must have authorization enabled. For the app config keys and environment variables of every instance type, see [Primary](/servicecontrol/servicecontrol-instances/configuration.md#authentication), [Audit](/servicecontrol/audit-instances/configuration.md#authentication), and [Monitoring](/servicecontrol/monitoring-instances/configuration.md#authentication) configuration. | |
| > [!WARNING] | |
| > Enable authorization consistently across all instances. If one instance is left with `RoleBasedAuthorizationEnabled` set to `false` while the others have it enabled, that instance grants every authenticated user full access to its endpoints, and ServicePulse will show those actions as available. Apply the same setting to Primary, Audit, and Monitoring. |
Comment on lines
+44
to
+49
| ```xml | ||
| <!-- Turn on role-based authorization --> | ||
| <add key="ServiceControl/Authentication.RoleBasedAuthorizationEnabled" value="true" /> | ||
| <!-- The token claim that carries the roles (see the table below) --> | ||
| <add key="ServiceControl/Authentication.RolesClaim" value="roles" /> | ||
| ``` |
Member
There was a problem hiding this comment.
Suggested change
| ```xml | |
| <!-- Turn on role-based authorization --> | |
| <add key="ServiceControl/Authentication.RoleBasedAuthorizationEnabled" value="true" /> | |
| <!-- The token claim that carries the roles (see the table below) --> | |
| <add key="ServiceControl/Authentication.RolesClaim" value="roles" /> | |
| ``` | |
| ```xml | |
| <!-- Turn on role-based authorization --> | |
| <add key="ServiceControl/Authentication.RoleBasedAuthorizationEnabled" value="true" /> | |
| <!-- The token claim that carries the roles (see the table below) --> | |
| <add key="ServiceControl/Authentication.RolesClaim" value="roles" /> | |
| <!-- Apply the same two keys on the Audit and Monitoring instances, swapping the | |
| "ServiceControl/" prefix for "ServiceControl.Audit/" and "Monitoring/" respectively --> | |
| ``` |
Comment on lines
+70
to
+72
| Every authorization decision — both allowed and denied — is written to a dedicated audit log so access can be reviewed and retained for compliance. Entries are emitted under the log category `ServiceControl.Audit` and formatted as [Elastic Common Schema (ECS)](https://www.elastic.co/guide/en/ecs/current/index.html) JSON, so they can be ingested into Elastic/Kibana or most SIEM (Security Information and Event Management) systems without custom mapping. Allowed decisions are logged at `Information` level and denied decisions at `Warning` level. | ||
|
|
||
| ### Audit identity claims |
Member
There was a problem hiding this comment.
Suggested change
| Every authorization decision — both allowed and denied — is written to a dedicated audit log so access can be reviewed and retained for compliance. Entries are emitted under the log category `ServiceControl.Audit` and formatted as [Elastic Common Schema (ECS)](https://www.elastic.co/guide/en/ecs/current/index.html) JSON, so they can be ingested into Elastic/Kibana or most SIEM (Security Information and Event Management) systems without custom mapping. Allowed decisions are logged at `Information` level and denied decisions at `Warning` level. | |
| ### Audit identity claims | |
| Every authorization decision — both allowed and denied — is written to a dedicated audit log so access can be reviewed and retained for compliance. Entries are emitted under the log category `ServiceControl.Audit` and formatted as [Elastic Common Schema (ECS)](https://www.elastic.co/guide/en/ecs/current/index.html) JSON, so they can be ingested into Elastic/Kibana or most SIEM (Security Information and Event Management) systems without custom mapping. Allowed decisions are logged at `Information` level and denied decisions at `Warning` level. | |
| ### Where the audit log is written | |
| ServiceControl routes the `ServiceControl.Audit` category to a dedicated destination automatically; no additional logging configuration is required. Each entry is a single ECS JSON object on its own line, kept separate from the operational log so the two streams do not mix. | |
| - **Running as a Windows service** (not in a container): entries are written to an `audit.json` file in the instance's log directory, alongside the console. The file rotates daily and when it exceeds 30 MB, retaining up to 14 archived files. | |
| - **Running in a container**: entries are written to standard output only, for the container's log driver or log aggregator to collect; no `audit.json` file is produced. | |
| The audit trail is captured from `Information` upward independently of the operational log level, so reducing operational verbosity never drops audit entries, and audit entries never appear in the operational log. | |
| ### Audit identity claims |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Documents role-based access control based on: