This documentation and the Cisco Observability Platform functionalities it describes are subject to change. Data saved on the platform may disappear and APIs may change without notice.
RBAC Modeling
The RBAC modeling for Access Management depends on the RBAC system solution that the Knowledge Store provides. The RBAC system solution includes a data model that can enforce RBAC without prescribing a specific implementation method. The data model instead defines which permissions are granted and to whom.
Because the data model focuses on permission, the RBAC is flexible enough to accommodate any type of resource, such as a Knowledge Store object or a REST/HTTP endpoint. For instance, a REST application could use the information to enforce HTTP permissions. Additionally, the Knowledge Store uses object type permissions to regulate its permissions.
In short, keep in mind the following to understand Access Management's RBAC model:
- The Knowledge Store provides a system solution for RBAC.
- The RBAC system solution includes a data model that documents permissions granted to roles. The roles are then assigned to users.
- The data model enforces permissions on different types of resources, but does not prescribe RBAC implementation.
- The Knowledge Store uses object type permissions to regulate its permissions.
Define REST Resources
The REST configuration names a resource and includes the HTTP methods, URI endpoint, and path.
{
"name": "can_launch_investigation",
"displayName": "Can Launch Investigation",
"kind": "http",
"actions": [
{
"verbs": [
"PUT",
"POST"
],
"context": {
"path": "/investigation",
"endpoint": "<customer>.observe.appdynamics.com/ext/securityboss"
}
}
]
}
Define Roles
A role is a name for a set of permissions defined at the solution, account, or tenant layer.
[
{
"name": "crudDashboard",
"displayName": "dashboardApp:crudDashboard",
"description": "Perform crud operations on dashboard",
"permissions": [
{
"id": "dashboardApp:canReadDashboard"
},
{
"id": "dashboardApp:canUpdateDashboard"
}
]
}
]
Define Permissions
Permission is a combination of resources and access actions restricted to a scope.
The RBAC doesn't state which dashboards the user can access in the following example. The policy instead states that a user request can send, create, and update requests to a dashboard service. Fine-grained access (coming soon) can be used to enforce that the update request can only target dashboard objects owned by a specific user.
[
{
"name": "canReadDashboard",
"displayName": "dashboardApp:canReadDashboard",
"description": "Read dashboard",
"scopes": ["ACCOUNT"],
"actionAndResources" : [
{
"action": {
"classification": "READ"
},
"resource": {
"type": "dashboard:Dashboard"
}
}
]
},
{
"name": "canUpdateDashboard",
"displayName": "dashboardApp:canUpdateDashboard",
"description": "Update Dashboard",
"actionAndResources" : [
{
"action": {
"classification": "CREATE"
},
"resource": {
"type": "dashboard:Dashboard"
}
},
{
"action": {
"classification": "UPDATE"
},
"resource": {
"type": "dashboard:Dashboard"
}
}
],
"scopes": ["TENANT", "ACCOUNT"]
}
]
Permissions Identified by Tags
{
"name": "qa_observer",
"displayName": "Can see read data from QA cluster",
"kind": "tags",
"actions": [
{
"verbs": [
"read"
],
"context": {
"tags": [
"qa_logs",
"qa_cluster4_logs"
]
}
}
]
}
Assignments: Map Roles and Permissions
An assignment links a user (or group) and a role. Assignments happen at the Tenant level, but can also be defined at the account level. You can use assignments in a solution package to assign a role (defined in the solution) to an existing group.
This configuration maps two roles to permissions to get and update a demo test at the account level.
[
{
"name": "tenantAdminPermissions",
"scopes": ["ACCOUNT"],
"roles": [
"iam:tenantAdmin",
"iam:configManager"
],
"permissions": [
{
"id": "dashboardApp:canReadDashboard"
},
{
"id": "dashboardApp:canUpdateDashboard"
}
]
}
]