Before the Session

Granting access safely.

How to give us what we need without opening up more than necessary. This guide covers both options — pick what works for your setup.

Never share root credentials. Root access has no permission boundaries, cannot be scoped, and every action taken with it is your full legal and security liability. There is no legitimate consulting scenario that requires root. If anyone asks for root credentials, treat it as a red flag.

Recommended

Cross-Account IAM Role

You create a role in your AWS account. We assume it temporarily via STS. No credentials are shared — access is granted and revoked by enabling or disabling the role.

  • No long-lived credentials to manage or rotate
  • Full CloudTrail audit trail on every access event
  • Revoke instantly — delete the role, access is gone
  • External ID prevents unauthorized assumption
Also Acceptable

Dedicated IAM User

Simpler to set up if you're not familiar with IAM roles. Create a dedicated IAM user with scoped permissions, generate access keys, and share them securely. Delete the user when the engagement ends.

  • Easier to set up for non-technical stakeholders
  • Long-lived keys require manual rotation
  • Keys must be transmitted and stored securely

If using this option: share keys via a secrets manager or encrypted channel — never email or Slack.

Permissions by Engagement Type

Engagement AWS Managed Policy What it covers
Audit / Security Review SecurityAudit Read-only across IAM, S3, EC2, VPC, CloudTrail, Config, GuardDuty and more. Purpose-built for security reviews.
General Read / Architecture Review ReadOnlyAccess Broader read-only across all services. Use when we need to understand your full architecture.
Implementation Work Agreed per engagement We define the minimum required permissions before starting. Never AdministratorAccess.

Option A — IAM Role

Console setup (step by step)

Takes about 5 minutes. After you book, we'll send you our AWS Account ID and your unique External ID via email — both are required to complete this setup.

01

Open IAM in the AWS Console

Navigate to IAM → Roles → Create role.

02

Select trusted entity type

Choose AWS account → Another AWS account.

Enter the KUBEX Account ID — we'll send it after you book.

Check Require external ID and enter the External ID we send you. Both values are unique per engagement.

03

Attach permissions

Search for and attach the appropriate managed policy:

  • Audit → SecurityAudit
  • Architecture review → ReadOnlyAccess
  • Implementation → we'll specify before starting

04

Name and create the role

Name it something clear: KubexAuditRole or KubexConsultingAccess.

Create the role and copy the Role ARN — send it to us before the session.

Option A — CloudFormation

One-click deployment

Prefer Infrastructure as Code? Run this template in CloudFormation — it creates the role with the correct trust policy and permissions. You'll be prompted for two values: our Account ID and your External ID, both sent after booking.

AWSTemplateFormatVersion: '2010-09-09'
Description: >
  KUBEX consulting access role.
  Creates a cross-account IAM role with SecurityAudit permissions.
  Delete this stack when the engagement is complete.

Parameters:
  KubexAccountId:
    Type: String
    Description: >
      KUBEX AWS Account ID — sent to you via email after booking.
      12-digit number, no dashes.

  ExternalId:
    Type: String
    Description: >
      Unique External ID for your engagement (provided by KUBEX).
      Prevents unauthorized role assumption.

  PolicyType:
    Type: String
    Default: SecurityAudit
    AllowedValues:
      - SecurityAudit
      - ReadOnlyAccess
    Description: >
      SecurityAudit for security reviews.
      ReadOnlyAccess for broader architecture reviews.

Conditions:
  UseSecurityAudit: !Equals [!Ref PolicyType, SecurityAudit]

Resources:
  KubexAccessRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: KubexConsultingAccess
      Description: Temporary consulting access for KUBEX engagement
      MaxSessionDuration: 3600  # 1 hour max session
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              AWS: !Sub 'arn:aws:iam::${KubexAccountId}:root'
            Action: sts:AssumeRole
            Condition:
              StringEquals:
                sts:ExternalId: !Ref ExternalId
      ManagedPolicyArns:
        - !If
          - UseSecurityAudit
          - arn:aws:iam::aws:policy/SecurityAudit
          - arn:aws:iam::aws:policy/ReadOnlyAccess
      Tags:
        - Key: Purpose
          Value: KUBEX-Consulting
        - Key: ManagedBy
          Value: KUBEX
        - Key: DeleteAfterEngagement
          Value: 'true'

Outputs:
  RoleArn:
    Description: >
      Send this ARN to KUBEX before your session.
    Value: !GetAtt KubexAccessRole.Arn
  RoleName:
    Value: !Ref KubexAccessRole

Deploy via CloudFormation → Create stack → Upload template. The Role ARN appears in the stack Outputs tab — send it to us.

Option B — IAM User

Console setup (step by step)

Simpler alternative if cross-account roles are unfamiliar. Delete the user when the engagement ends.

01

Create a dedicated IAM user

Navigate to IAM → Users → Create user. Name it clearly: kubex-consulting.

Select Programmatic access only — no Console access needed.

02

Attach permissions directly

Attach the appropriate managed policy: SecurityAudit or ReadOnlyAccess.

Do not attach AdministratorAccess or any policy with wildcard * actions unless specifically agreed for implementation work.

03

Generate and share access keys securely

After creating the user, generate access keys. Share them via a secure channel only:

  • 1Password / Bitwarden secure share link
  • AWS Secrets Manager (share the secret ARN)
  • Encrypted email (PGP)

Not email in plain text. Not Slack. Not chat.

After the engagement — revoke access

IAM Role: Delete the CloudFormation stack or delete the role directly from IAM → Roles. Access is immediately revoked for all future sessions.

IAM User: Go to IAM → Users → select the user → delete. Deactivate the access keys first if you want to test revocation without deleting.

We will remind you to do this at the end of each engagement. You can verify no active sessions exist via CloudTrail → Event history filtered by AssumeRole or the username.

Ready?

Book the free session or Ask a question first