Entrypoint AWS Accounts for third party services

Isolating third party access to AWS organizations using entrypoint accounts

Table Of Contents

Today I Explained

When setting up third party services with AWS, using technologies like OpenID Connect¹², if your AWS organization has numerous AWS Accounts it can result in many ways in which third party services has access into your infrastructure. Without proper tagging or audit controls, this can become a genuine pain point during compliance & audits, as tracking them all down will be an exercise.

Tagging or using paths can assist with identifying them, but still spreads the access across the entire AWS organization. A common approach that comes up to address this clutter is the use of a centralized AWS Account responsible for allowing third party access into the AWS organization. This builds on the recommended OUs and accounts, which is similar to:

    ┌─────────┬───────OU Root────────┬────────────┐
    │         │          │           │            │
    ▼         ▼          ▼           ▼            ▼
Security    Audit   Workloads   Infrastructure   ...

A tree structure with a top level node named ‘OU Root’ with 5 child nodes named, ‘Security, ‘Audit’, ‘Workloads’, ‘Infrastructure’ and ‘…’ to mean “and so on”.

This approach restricts access patterns for third party services into the AWS organization, by only allowing it for AWS Accounts within a certain OU, named as External or Entrypoint:

    ┌─────────┬───────OU Root───────┐
    │         │          │          │
    ▼         ▼          ▼          ▼
Entrypoint  Audit    Workloads     ...

A tree structure with a top level node named ‘OU Root’ with 4 child nodes named, ‘Entrypoint, ‘Audit’, ‘Workloads’ and ‘…’ to mean “and so on”.

This can be somewhat enforced using service control policies (SCPs) that limit actions in this space, although that can be difficult without blocking other necessary cross-account infrastructure such as billing analysis, or services within other workload accounts. In the entrypoint accounts, services can be configured that are responsible for monitoring the behaviour & activity of these roles to detect potential concerning behaviour from these third party services.

In practical cases, these third party services will likely rank fairly high in terms of trust, so this approach is likely not warranted. Despite that, this approach does provide a direction for having a strict handle on the approach to third party integrations within an AWS organization.