1. Kion Success Center
  2. Cloud Rules
  3. Getting Started

Managing Cloud Rules

Follow

Last updated

Managing Cloud Rules on Resources

Cloud rules can be attached to any OU or project that you have permission to manage. When you attach a cloud rule to an OU, it will apply the cloud rule to all of the OU's descendant projects. This allows you to update all of the necessary projects by creating/editing the cloud rule in a single place.

Cloud rule application can also be automated using action plans. For more information, see Applying Cloud Rules with Action Plans.

For information on how cloud rules are inherited between resources, see Cloud Rule Inheritance and Exemption.

To access the cloud rules section of a resource:

  1. In the left navigation menu, click OUs or Projects.
  2. Click the name of the resource you want to manage.
  3. Click the Cloud Management tab. The Cloud Rules sub-tab shows by default.

On this screen, you can view information about cloud rules and their origin and status.

ClosedTo create a new cloud rule and apply it to a resource

ClosedTo add an existing cloud rule to a resource

ClosedTo remove a cloud rule from a resource

Cloud Rule Effects

When a cloud rule is applied to a resource, the following actions occur on all descendant projects:

  • All AWS IAM policies on the cloud rule are applied to all IAM roles on the projects. When AWS IAM policies are stacked, they follow the AWS IAM policy evaluation. This is powerful because any policies with the Deny effect will take precedence over any policies with the Allow action. This allows you to use policies with a Deny effect and a Not Action key to limit which services are allowed, even if an administrative policy is applied to the same IAM role. These IAM policies don't affect other roles that exist in the AWS account that are not managed by Kion.
  • The pre-rule webhook and the post-rule webhook trigger on each AWS account.
  • Each AWS CloudFormation template on the cloud rule is applied (in order) to the AWS accounts attached to the projects. If any of the templates fail, they stop execution and show up on the OU Diagnostics screen, which can be accessed from the ellipsis menu on the OU card. You can use these to baseline the AWS accounts with templates that set up AWS CloudTrail and config.
  • All AWS AMIs are shared with the AWS accounts attached to the projects.
  • All AWS service catalog portfolios are shared with the AWS accounts attached to the projects.
  • On each project, all Azure role definitions on the inherited cloud rule are merged with the role definitions on each local cloud access role to create a single role definition on each cloud access role. This ensures the "notActions" sections of Azure definitions are applied to all descendants. When this is utilized in the higher levels of your organization, you can ensure specific permissions are denied, even if someone gives themselves a role lower in the hierarchy which might allow them to perform a restricted action. However, cloud rules do not affect cloud access roles that were created higher in the organizational heirarchy. For more information, see Cloud Rule Inheritance and Exemption
  • Each Azure ARM template creates the resource group mentioned in the ARM template definition if it does not exist, then applies the ARM template to that resource group for every Azure subscription on every project under this OU. This happens in order the ARM templates are listed in on the cloud rule.
  • All Azure policies on the cloud rule are applied to Azure subscriptions.

If there is more than one cloud rule applied to a project, there is no guarantee to the order of execution. Inside of a cloud rule, the only guaranteed ordering is: pre-rule webhook, AWS CloudFormation templates, post-rule webhook. The remainder of the items will all apply at the same time.