AWS logo

AWS

CloudCloud IAM roleLive

Connect your customers' AWS accounts to your product without ever asking them to hand over access keys. Askel uses a cross-account IAM role so you read only what you need, and customers can revoke access in one click.

What you can do

Inventory EC2, RDS, and S3 without write access

Askel reads instance types, running state, storage volumes, bucket names, and database engine versions. The default role carries SecurityAudit only, so nothing in the customer's account can be changed unless they explicitly grant write permissions.

Inspect IAM users, roles, and policies

Pull the full list of IAM principals, their attached policies, MFA status, and last-used dates. Useful for access-review workflows and security-posture checks during onboarding.

Read CloudTrail events for audit trails

Fetch recent management events from CloudTrail to surface what changed in a customer's account and when. Pair this with your own product's activity log for a complete picture.

Check AWS Config rules and compliance state

Query Config rule results to see which resources are compliant and which are not. Lets your product surface compliance drift without customers needing to file support tickets.

Cover multiple regions in a single connection

One IAM role covers all regions. Your product can query us-east-1, eu-west-1, or any other region the customer operates in without additional setup steps.

Support multi-account AWS Organizations

Customers running an AWS Organization can deploy the CloudFormation stack in each member account. Askel tracks each account separately so your product can show a consolidated view across the org.

Sample use case

Onboarding a cloud-security customer to your posture platform

You sell a cloud security posture product. A new customer, Ridgeline Analytics, runs their data platform on AWS across three accounts: production, staging, and a shared-services account. Your product needs to read their EC2 instances, S3 bucket policies, IAM roles, and Config rule results on day one so their security team can see their baseline posture before the kickoff call.

  1. 1

    Deploy the CloudFormation stack

    Ridgeline's AWS admin logs into the production account and clicks the one-click stack link from your product's onboarding wizard. The stack creates a cross-account IAM role named AskelReadRole with a SecurityAudit policy attached and Askel's account ID plus a unique externalId in the trust policy. The whole process takes about three minutes.

  2. 2

    Paste the role ARN

    The admin copies the role ARN from the CloudFormation outputs tab and pastes it into the connection form in your product. Askel immediately calls AssumeRole to verify the role is reachable before saving the connection.

  3. 3

    Repeat for staging and shared-services

    The admin deploys the same stack template in the staging and shared-services accounts. Each stack produces a separate role ARN. They add both to Askel as additional connections under the same customer record.

  4. 4

    Initial inventory pull

    Askel fans out read calls across all three accounts: EC2 DescribeInstances, S3 GetBucketPolicy, IAM GetAccountAuthorizationDetails, and Config DescribeComplianceByConfigRule. Your product receives structured data for each resource type within a few minutes.

  5. 5

    Posture report ready before the kickoff call

    Your customer-success team opens the posture dashboard and sees Ridgeline's baseline: 47 EC2 instances, 12 S3 buckets with public-access settings flagged, 6 Config rules failing, and 3 IAM users without MFA. The kickoff call now starts from a concrete list of findings rather than a blank slate.

Authentication

Cloud IAM role

Customer's AWS admin deploys a one-click CloudFormation stack that creates a cross-account IAM role with a least-privilege SecurityAudit policy. Askel assumes the role with an externalId on every request; no long-lived AWS credentials are ever stored. Customers can swap the default policy for a custom one when they need write access.

Data flow

How Askel sits between your product and the customer's system

Data flow between Customer's AWS account, Askel, and Your productCustomer's AWS accountAPI endpointAskelauth · mapping · driftYour productyour backend
EC2 instancesS3 bucketsIAM users and rolesCloudTrail eventsConfig rulesRDS databases

FAQ for AWS

Do you store our AWS credentials or access keys?+
No. Askel never asks for or stores AWS access keys. The integration uses an IAM role that Askel assumes on each request using STS AssumeRole with a unique externalId tied to your account. The temporary credentials from STS expire after one hour and are never written to disk.
What permissions does the IAM role actually need?+
The default CloudFormation stack attaches AWS's managed SecurityAudit policy, which grants read-only access across most services. If your use case needs write access (for example, creating SSM parameters or tagging resources), your admin can attach an additional custom policy to the same role after deployment.
How do we revoke Askel's access?+
Delete or disable the AskelReadRole in your AWS account. You can do this from the IAM console, by deleting the CloudFormation stack, or by removing Askel's account from the role's trust policy. Access stops immediately because each API call requires a fresh AssumeRole call.
Does this work if we have multiple AWS accounts in an Organization?+
Yes. Deploy the CloudFormation stack once in each member account you want Askel to read. Each account appears as a separate connection in Askel, and your product can query them independently or aggregate them. You do not need to use AWS Organizations delegation; each account is self-contained.
Ready to ship integrations faster?customers faster?implementations faster?
Join onboarding teams delivering integrations without the engineering queue,
catching drift before it breaks, and hitting go-live dates.
Security & Compliance
ISO 27001 Certified
GDPR Compliant

© 2025 Askel.ai. All rights reserved.