Getting Started with Permissions

Follow

Getting Started with Permissions

Kion's permission system has multiple layers of control for flexibility in assigning permissions. This system relies on permissions, permission roles, and permission schemes.

  • Permission. Individual capabilities that can be assigned within Kion, such as the capability to browse, request, create, or manage an item. These Kion permissions are separate from the permissions within your cloud accounts. Some permissions can be implied. For example, the Manage Funding Sources permission also allows users to view OUs, because funding sources are applied to OUs.
  • Permission role. A role you can create, such as Admin or Analyst, that will be assigned individual permissions using one or more permission schemes.
  • Permission scheme. Permission schemes map individual permissions to permission roles. For example, you can create a permission scheme that assigns a collection of permissions to the Admin permission role. Permission schemes are also used associate users or user groups with permission roles.

Permission Assignment Flow

A typical process to assign permissions includes creating a permission role, assigning permissions to the role via permission scheme, and associating a user or user group with the permission role.

For example, let's say I wanted to grant Steve the necessary permissions to manage finances in Kion. I would:

  1. Create a Finance permission role.
  2. In the Global Permissions Scheme, assign the Finance role manage funding sources, browse billing sources, and browse global reports permissions.
  3. Create a Finance user group, and add Steve to it.
  4. In the Global Permissions Scheme, associate the Finance user group with the Finance permission role.

In other words:

  1. Create a Permission Role.
  2. Edit a Permission Scheme.
  3. Add a User Group.
  4. Mapping Users to Permission Roles.

Default Permission Schemes

Out of the box, we provide you with four default permission schemes. In most cases, you can use these four schemes to cover all of your permission assignment needs.

  • Global Permissions. Permissions that apply to the entire Kion application.
  • OU Permissions. Permissions that can be applied to OUs.
  • Project Permissions. Permissions that can be applied to Projects.
  • Funding Source Permissions. Permissions that can be applied to Funding Sources.

Best Practices

Automation

You can use our public API to manage large numbers of users and permissions. Specifically, the permission-mapping and permission-scheme endpoints are helpful here. For more information, see Getting Started with the Kion Public API.

It is considered best practice to automatically assign permissions to users using group associations/assertions. This helps ensure that appropriate permissions are always applied. For more information, see User Group Associations or Active Directory Group Assertions.

Grant Minimum Permissions

The principle of least privilege is considered a best practice when managing permissions. Using permissions schemes, you can control what parts of the application users have access to. Similar to managing access in cloud consoles, we recommend thinking through the various roles within your organization and the minimum amount of permissions they need.

For example, someone in the finance department would likely need permissions to manage funding sources, browse billing sources, and browse global reports. They probably wouldn't need permission to create projects or manage user groups.

It is also worth considering that Kion is intended to provide users and stakeholders visibility into their impact on their organization's cloud environment.

  • If someone generates spend on a project or OU, consider allowing them to browse financials for the resources they use. Being able to see their impact may help them consider the necessity of spinning up more resources.
  • If someone generates infrastructure within a given project’s accounts, consider allowing them to see compliance results for those resources. This may help them identify configurations they use that put the organization at risk.