policy_document

IAM policy document builders.

Provides utilities for creating and managing complete AWS IAM policy documents. Includes builders for common policy types and helpers to combine policy statements into properly formatted policy documents.

cdkit.srv.iam.policy_document.create_get_caller_identity_document(policy_statement_kwargs: Dict[str, Any] | None = None, policy_document_kwargs: Dict[str, Any] | None = None) → PolicyDocument

Allows the caller to get their identity.

cdkit.srv.iam.policy_document.create_assume_role_document(role_to_assume_arn_list: list[str], policy_statement_kwargs: Dict[str, Any] | None = None, policy_document_kwargs: Dict[str, Any] | None = None) → PolicyDocument

Allow assuming specific roles.

Parameters:

role_to_assume_arn_list – List of ARNs of roles to assume.

cdkit.srv.iam.policy_document.create_power_ops_document(policy_name: str, prefix: str) → PolicyDocument

Create an IAM policy document that grants broad AWS access with strict identity management controls.

Parameters:

• policy_name – The name of the IAM policy to be used as a permissions boundary for role creation.

• prefix – The required prefix for IAM roles and policies that users are allowed to manage.

🎯 Scope of Permissions

• Grants broad operational capabilities, excluding identity management. Users can perform actions across most AWS services—similar to having “Administrator” access— but are explicitly restricted from managing the following identity-related services:

  • AWS IAM

  • AWS Organizations

  • AWS Account

🛡️ Identity Management Restrictions and Exceptions

• Read-only access to IAM, Organizations, and Account services. Users can view configuration details of these resources but cannot create or modify them.

• Fine-grained IAM access control:

  • Users are allowed to manage only IAM roles and policies that start with a designated company-specific prefix (e.g., “ESC”).

    • For example, users can create, update, or delete roles like ESC-MyServiceRole.

    • Roles that do not start with the prefix are protected and cannot be modified, ensuring critical permissions are not compromised.

  • All IAM resources (regardless of prefix) are readable, allowing users to inspect existing role configurations.

🧱 Enforced Permissions Boundary for Role Creation

• When creating a new IAM role, users must attach the current IAM policy as a permissions boundary.

• This prevents privilege escalation scenarios (e.g., creating a new role with full admin access and assuming it).

• All new roles inherit the boundary, ensuring their permissions remain within the limits defined by this policy.

✅ Summary

This policy establishes a model of “controlled high-level access”:

• Users can perform most day-to-day operational tasks, including deployment, maintenance, and AWS service management.

• Identity management is tightly restricted to specific prefixed IAM roles.

• The enforced permissions boundary mechanism ensures no user can exceed the defined privilege scope, maintaining system security and control.

cdkit.srv.iam.policy_document.create_restricted_read_only_document(policy_name: str) → PolicyDocument

Create an IAM policy document that grant read-only access across a wide range of AWS services, excluding any write or management actions.

Parameters:

policy_name – The name of the IAM policy to be used as a permissions boundary for role creation.