Amazon Web Services (AWS) Identity and Access Management (IAM) integration provides comprehensive visibility into your AWS account’s identity infrastructure, bringing critical cloud identity and permission data into SGNL for sophisticated access control decisions. This integration focuses specifically on IAM entities including users, roles, groups, policies, and their complex relationships within your AWS environment.
The AWS integration is particularly valuable for organizations implementing Zero Trust architectures where cloud identity context must inform access decisions across hybrid environments. By understanding who has what permissions in AWS, SGNL can make more informed decisions about access to related systems and resources throughout your infrastructure.
To successfully configure the AWS integration, you need AWS credentials with the following IAM permissions. These permissions allow SGNL to read identity and access management information without the ability to modify your AWS configuration:
Core IAM Read Permissions: The integration requires read access to users, roles, groups, policies, and identity providers. Specifically, you need permissions for iam:ListUsers, iam:ListRoles, iam:ListGroups, iam:ListPolicies, and iam:ListSAMLProviders.
Policy and Attachment Information: To understand the relationships between identities and their permissions, the integration needs access to policy attachments through permissions like iam:ListAttachedUserPolicies, iam:ListAttachedRolePolicies, and iam:ListAttachedGroupPolicies.
Group Membership Details: Understanding organizational structure requires permissions to read group memberships through iam:GetGroupsForUser and iam:GetGroup.
Detailed Entity Information: For comprehensive identity context, the integration needs permissions to get detailed information about each entity type through iam:GetUser, iam:GetRole, iam:GetPolicy, and related detail operations.
We recommend creating a dedicated IAM user or role specifically for SGNL integration with a custom policy that includes only the necessary read permissions. This follows the principle of least privilege while ensuring the integration has access to all required identity data.
The AWS integration uses Access Key ID and Secret Access Key authentication. You can create these credentials through a dedicated IAM user.
The AWS integration requires you to specify the AWS region where your IAM resources are primarily located. While IAM is a global service, specifying the correct region ensures optimal performance and proper API endpoint usage. Most organizations use their primary operational region, such as “us-east-1” or “eu-west-1”.
Before configuring SGNL, review your AWS IAM structure to understand the entities and relationships that will be most valuable for your access policies. Consider how your AWS users, roles, and groups relate to identities in other systems, and identify any custom naming conventions or organizational patterns that might inform your SGNL policy design.
The AWS integration uses HTTP Basic Authentication with your AWS credentials configured as follows:
This authentication approach follows AWS’s standard practice for API access using programmatic credentials. Ensure that these credentials are securely managed and rotated according to your organization’s security policies.
Complete the required configuration parameters for your AWS integration:
AWS Region: Replace the {{Input Required: aws_region}} placeholder in the adapter configuration with your target AWS region identifier (such as “us-east-1”, “eu-west-1”, or “ap-south-1”). This region setting determines which AWS endpoints the integration uses for API calls.
Request Timeout: The adapter configuration includes a request timeout setting that controls how long SGNL waits for responses from AWS APIs. The default timeout is typically sufficient, but you may need to adjust this value if you have a large number of IAM entities or experience network latency issues.
The AWS template defines several interconnected entities that represent the complete IAM structure within your AWS account. Understanding these entities and their relationships is crucial for effective policy creation.
Identity Provider Entity: Represents AWS IAM SAML providers that enable federated access to your AWS account. This entity includes the provider ARN, account ID, creation date, and validity information. Identity providers are essential for understanding how external identity systems connect to your AWS environment.
User Entity: Represents individual IAM users within your AWS account. Each user entity includes the user ARN, account ID, creation date, password last used timestamp, path information, permissions boundary details, user ID, and username. This comprehensive user information enables policies based on user activity, organizational placement, and security constraints.
Role Entity: Represents IAM roles that can be assumed by users, services, or external entities. Role entities include the role ARN, account ID, assume role policy document, creation date, description, maximum session duration, path, permissions boundary, role ID, last used information, and role name. Roles are central to AWS security architecture and provide rich context for access decisions.
Group Entity: Represents IAM groups that organize users for permission management. Group entities include the group ARN, account ID, creation date, group ID, group name, and path information. Groups provide organizational context that can inform access policies based on team or department structures.
Policy Entity: Represents IAM policies that define permissions within AWS. Policy entities include comprehensive information such as ARN, account ID, attachment count, creation date, default version ID, description, attachability status, path, permissions boundary usage count, policy ID, name, and update date. Understanding policy attachments and usage is crucial for access decisions.
Relationship Entities: The template includes several entities that represent relationships between the core IAM entities. GroupMember entities represent user membership in groups, while GroupPolicy, RolePolicy, and UserPolicy entities represent policy attachments to their respective identity types. These relationship entities enable SGNL to understand the complete permission structure within your AWS account.
The AWS template establishes sophisticated relationships that mirror the complex permission inheritance and policy attachment patterns in AWS IAM. These relationships enable SGNL policies to reason about indirect permissions and role-based access patterns.
Direct Policy Assignments: The template creates direct relationships between users, roles, and groups with their assigned policies. These relationships enable policies that consider what permissions each identity type has been explicitly granted.
Group Membership Relationships: User membership in groups is represented through a two-step relationship that connects users to group memberships and then to the groups themselves. This structure enables policies that consider group-based permissions and organizational hierarchies.
Policy Inheritance Paths: The template defines path relationships that trace permission inheritance from identity providers through roles to policies. This enables sophisticated policies that understand how federated identities acquire permissions in your AWS environment.
Composite Permission Views: Several path relationships combine multiple direct relationships to provide consolidated views of permissions. For example, the UserPolicy path relationship traces from users through their policy assignments to the actual policies, enabling policies that reason about a user’s complete permission set.
After configuring the AWS integration, systematic testing ensures that your identity data is being correctly imported and that the complex IAM relationships are properly established.
The AWS integration includes multiple related entities that should be enabled systematically to ensure complete relationship mapping:
Once synchronization is complete, use DataLens to explore your AWS IAM data and validate the relationships:
Credential Authentication Failures: If SGNL cannot authenticate with AWS, verify that your Access Key ID and Secret Access Key are correctly entered and that the credentials haven’t been rotated or deactivated. Test the credentials using AWS CLI or another AWS tool to confirm they work outside of SGNL.
Insufficient Permissions: If synchronization fails with permission errors, review the IAM permissions attached to your credentials. The integration requires read access to all IAM entity types, and missing permissions for any entity type will cause synchronization failures. Consider enabling AWS CloudTrail to see exactly which API calls are being denied.
Region Configuration Problems: If you receive region-related errors, verify that your specified region is correct and that your credentials have access to IAM resources in that region. Remember that while IAM is a global service, the region setting affects which API endpoints are used.
Large Account Performance: AWS accounts with thousands of IAM entities may experience slow synchronization times. The default API call frequency settings are designed to respect AWS rate limits, but you may need to adjust timing parameters for very large accounts. Consider whether you need to synchronize all entities or can filter to specific organizational units.
Relationship Mapping Issues: If relationship entities are not properly connecting core entities, ensure that all core entities (User, Role, Group, Policy) have completed their initial synchronization before the relationship entities begin synchronizing. The relationship entities depend on the core entities being present in SGNL’s graph.
Policy Attachment Complexity: Some AWS accounts have complex policy attachment patterns including permissions boundaries, service-linked roles, and AWS managed policies. If certain policy relationships are not appearing correctly, review your AWS account structure to understand any non-standard configuration patterns.
Identity Provider Integration: If SAML identity provider information is not synchronizing correctly, verify that your credentials have access to list and read SAML providers and that your AWS account actually uses SAML federation. Accounts that only use direct IAM users may not have identity provider entities.
API Rate Limiting: AWS IAM APIs have rate limits that can affect synchronization of large accounts. The default configuration respects these limits, but if you encounter throttling errors, you may need to reduce the API call frequency in the template configuration.
Memory and Processing: Large AWS accounts with complex IAM structures require significant processing power to map all relationships. Monitor SGNL’s resource usage during initial synchronization and consider breaking very large synchronizations into smaller batches if necessary.
Network Connectivity: Ensure that SGNL can reach AWS API endpoints consistently. Network issues or DNS resolution problems can cause intermittent synchronization failures that may be difficult to diagnose.
Once your AWS integration is successfully configured and synchronized, you can leverage the comprehensive IAM data in sophisticated SGNL policies that bridge cloud and on-premises access decisions.
Role-Based Access Control: Use AWS role information to create policies that grant access to external resources based on AWS role assignments. For example, users who can assume specific AWS roles might be granted corresponding access to on-premises systems or third-party applications.
Policy-Driven Permissions: Leverage AWS policy attachments to inform access decisions in other systems. Users with specific AWS managed policies might automatically receive related permissions in connected applications, creating consistent permission models across your infrastructure.
Group-Based Organization: Use AWS group memberships to extend organizational structure into other systems. AWS groups that represent departments or teams can inform access policies for non-AWS resources, maintaining consistent organizational boundaries.
Federated Identity Integration: For organizations using AWS as an identity hub, the identity provider information can inform policies about how users authenticate and what external identity systems they originate from. This enables policies that consider the full identity chain from external providers through AWS to target resources.
Temporal Access Patterns: Use AWS usage information such as last login dates and role usage patterns to create dynamic access policies that consider user activity levels and role utilization patterns when making access decisions.
For comprehensive guidance on creating policies with AWS identity data, refer to the SGNL Policy Management documentation. For understanding how AWS entities relate to other identity systems in your environment, review the Entities and Relationships guide.