-
Notifications
You must be signed in to change notification settings - Fork 34
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Adding Managing policies docs (#1426)
* adding managing policies * Update content/docs/details/managing-policies/index.md Co-authored-by: Jussi Hallila <[email protected]> * Update content/docs/details/managing-policies/index.md Co-authored-by: Jussi Hallila <[email protected]> * requested changes * remove warning * change disclaimer to policies --------- Co-authored-by: Jussi Hallila <[email protected]>
- Loading branch information
1 parent
e6ca0f0
commit 7bacc41
Showing
3 changed files
with
59 additions
and
14 deletions.
There are no files selected for viewing
This file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,42 @@ | ||
--- | ||
title: Policies Management | ||
publishedDate: '2024-11-05T21:00:00.0Z' | ||
description: How to configure and manage policies in Roadie for access control. | ||
--- | ||
|
||
## Introduction | ||
|
||
**This feature is currently in the process of being rolled out. If you want access, please contact our support or sales teams.** | ||
|
||
In Roadie, **policies** are integral components of the permissions framework, governing access control within the platform. They define the rules and conditions under which users can perform specific actions on various resources, such as services, components, or documentation. | ||
|
||
**Key aspects of policies:** | ||
|
||
- **Authorization Decisions:** Policies determine whether a user is permitted to execute a particular action. For instance, a policy might allow only the owner of a service to delete it from the catalog. For more on policy definitions, refer to the [Backstage documentation](https://backstage.io/docs/permissions/writing-a-policy/). | ||
- **Conditional Logic:** Policies can incorporate complex conditions, such as verifying if a user belongs to a specific group or possesses certain attributes, to make nuanced authorization decisions. Details are available in the [Backstage documentation on custom rules](https://backstage.io/docs/permissions/custom-rules/). | ||
- **Customization:** Administrators have the flexibility to craft custom policies tailored to their organization's unique requirements, ensuring that access controls align with internal processes and security standards. Read more in the [Backstage custom rules documentation](https://backstage.io/docs/permissions/custom-rules/). | ||
|
||
By implementing policies, Roadie ensures that access to resources is managed effectively, enhancing security and maintaining the integrity of the development environment. | ||
|
||
To configure this in Roadie we provide a UI for **Policies Management** and you can access it at: `https://<tenant name>.roadie.so/administration/settings/policies`. | ||
|
||
Currently, a set of permissions is available from the upstream Backstage project, with the option to create and validate new permissions. | ||
|
||
- Built-in policies cannot be modified or removed, but they can be added to or removed from roles. | ||
- Each policy can be configured with an effect to either **ALLOW** or **DENY** the specified permissions and the conditions set for the policy. | ||
|
||
### Conditions for Configurable Permissions | ||
|
||
Some permissions allow configuration with a set of conditions, particularly those starting with `catalog.entity.`. These conditions enable access customization based on defined rules. Currently, these are the available rules: | ||
|
||
| Rule Name | Parameters | Description | | ||
| --------------------- | --------------------- | --------------------------------------------------------------------------- | | ||
| isEntityOwner | None | Checks if the user is the owner of the entity. | | ||
| isUserEntity | None | Checks if the entity represents the current user. | | ||
| hasOwnEntityName | None | Validates that the entity has its own unique name. | | ||
| hasOwnEntityNamespace | None | Confirms that the entity has its own designated namespace. | | ||
| hasEntityKind | `kinds` | Checks if the entity is of a specific kind (e.g., Component, API). | | ||
| hasSpec | `key`, `value` | Verifies the entity’s specification includes a specific key-value pair. | | ||
| hasMetadata | `key`, `value` | Ensures the entity metadata contains a specific key-value pair. | | ||
| hasLabel | `label` | Checks if the entity includes a specific label in its metadata. | | ||
| hasAnnotation | `annotation`, `value` | Validates the presence of a particular annotation in the entity’s metadata. | |
This file contains 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
This file contains 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