Identity and Permissions

Last Updated: 2026-06-09

Planning guide for the three identities Roadrunner SMB™ requires, AWS® deployer IAM tiers, and Active Directory® delegation. All guidance is self-service in published documentation.

In this guide:

• Identity overview
• Deployer vs runtime IAM
• Evaluation vs secure production
• Identity 1 — AWS Deployer
• Identity 2 — Appliance Owner
• Identity 3 — Active Directory
• Security reviewer checklist

Core framing

Identity 1 builds it. The AWS Deployer launches the Marketplace CloudFormation® stack (install-time only).

Identity 3 runs it day-to-day. An Active Directory administrator joins the domain once and manages the appliance through the Admin UI.

Identity 2 rescues it. The local Appliance Owner account (rrsmb-admin) provides break-glass Admin UI access when AD is unreachable.

These are three separate trust domains with different lifetimes. None requires superuser privileges by default — scoped alternatives exist for production.

See also: Quick Start — Identities and permissions (planning) · Deployment Guide — IAM planning · Security overview

Identity overview

What sits in each domain

Trust separation: The AWS Deployer is not the appliance runtime identity. The stack creates least-privilege IAM roles in your account (TaskRole, TaskExecutionRole, InstanceRole). Roadrunner SMB receives no standing AWS credentials from you at runtime — see the dashed runtime IAM box in the diagram above.

Deployer vs runtime IAM

When you launch from AWS Marketplace, your IAM principal (Identity 1) calls CloudFormation. CloudFormation creates resources and runtime roles the appliance uses after deploy.

Install-time flow: Deployer → CloudFormation (CreateStack, PassRole) → stack resources + runtime IAM roles.

Runtime (not the deployer): TaskExecutionRole (image pull, logs, secrets) · TaskRole (DynamoDB®, EFS, auto-update, metering) · InstanceRole (ECS agent, SSM).

Launch capabilities

You must acknowledge at stack create:

• IAM resources with custom names — the nested template creates named IAM roles.
• CAPABILITY_AUTO_EXPAND — the launcher creates a nested inner stack.

See Deployment Guide — Marketplace launch and AWS Marketplace deployment summary.

Stack-created roles (runtime — not the deployer)

Evaluation vs secure production

Using broad admin credentials for a proof-of-concept is a customer choice — common and supported for time-boxed evaluation. For audited production environments, use scoped identities below.

Tradeoffs of eval shortcuts: larger blast radius, harder credential rotation, and audit findings. Production guidance below minimizes privilege without requiring superuser for any identity.

Identity 1 — AWS Deployer

Three tiers — pick based on your security posture.

Tier 1 — Evaluation (simplest)

Sufficient for POC; not the production requirement.

• AdministratorAccess (or your organization's full-admin equivalent)
• Marketplace subscribe: attach AWSMarketplaceManageSubscriptions or broader AWSMarketplaceFullAccess
• First deployment only: iam:CreateServiceLinkedRole to create AWSServiceRoleForMarketplaceDeployment (AWS Marketplace Quick Launch)

Tier 2 — Pragmatic

• AWSMarketplaceManageSubscriptions (subscribe/unsubscribe)
• Organization-standard CloudFormation deploy role with iam:PassRole for stack-created roles
• Acknowledge nested stack + named IAM capabilities at launch

Tier 3 — Enterprise minimum

For security-conscious deployments:

1. Deployer permission matrix — template-derived CFN resources → AWS services → typical deployer actions
2. AWS services used by the nested stack: CloudFormation, S3, IAM, Lambda, ECS, EC2, Auto Scaling, Elastic Load Balancing, EFS, DynamoDB, Secrets Manager, CloudWatch Logs
3. Self-service CloudTrail procedure — derive and prove a scoped policy in your lab account
4. Validated deployer JSON — when published for your release, version-tagged alongside the permission matrix. Until then, use the matrix and CloudTrail procedure.

Enterprise IAM teams may also reference AWS Prescriptive Guidance — least privilege for CloudFormation.

Self-service CloudTrail capture procedure

Use this to build and prove a least-privilege deployer policy:

1. Enable CloudTrail in a non-production AWS account (management events, all regions used for deploy).
2. Deploy Roadrunner SMB once using a principal you will scope (or Tier 1 for capture-only, then replace).
3. Filter CloudTrail event history to your deployer principal ARN and the stack-creation time window (parent + nested stack creates/updates).
4. Collect eventName values — group by service (cloudformation:*, iam:*, ec2:*, etc.).
5. Draft an IAM policy from captured actions; include iam:PassRole scoped to roles the template creates.
6. Acceptance test: delete the stack (or use a fresh account), re-deploy using only the scoped policy (not admin). Successful CREATE_COMPLETE on parent and nested stacks proves completeness.
7. Maintain: when Roadrunner SMB releases update CloudFormation templates, repeat capture or apply the published validated JSON for that release.

Cross-check captured actions against the Deployer permission matrix.

Identity 2 — Appliance Owner (break-glass)

Set during First-Time Setup (wizard step Owner password, after domain join).

Best practices

• Store the password in a password vault; treat as break-glass only
• Do not use for routine administration (use Identity 3)
• Document recovery if the password is lost while AD is also unavailable

See also: Admin Guide — Accessing the Admin UI · FAQ — Appliance Owner

Identity 3 — Active Directory Administrator

Two sub-roles: one-time domain join and ongoing appliance administration.

3a — Domain-join account (one-time, FTS Step 3)

Domain Admin is not required. Security teams can delegate minimum rights on an organizational unit (OU) or pre-staged computer object.

Default Roadrunner SMB behavior:

• Join uses standard Samba net ads join
• Creates a computer object in AD (or re-joins an existing object with matching name)
• Computer name auto-allocated as RRSMB-NODE<n> unless overridden
• Optional OU when specified in the join step
• Post-join, computer description set to Roadrunner SMB Appliance

Enterprise best practice — pre-staged computer object: Microsoft supports delegating permissions on a pre-created computer object. This path is recommended for production but has not been end-to-end validated by Roadrunner SMB — validate in your lab.

Delegation checklists: AD domain join delegation

Network prerequisites (appliance subnet → domain controllers): Kerberos 88, LDAP 389 / LDAPS 636, DNS 53, SMB/RPC 445. See VPC Prerequisites — Active Directory.

Microsoft reference: Active Directory domain join permissions.

3b — Appliance administrator (ongoing)

After FTS Claim Appliance Admin, Admin UI access is granted through:

Important: During First-Time Setup only, domain join clears the registered admin registry so you can claim admin again if FTS is retried. Re-joining the domain from Settings after FTS does not automatically remove registered admins — manage ongoing access via Settings.

Configure Domain Admins and admin group: Admin Guide — Settings.

Security reviewer checklist

• Three identities understood; deployer credentials not used at appliance runtime
• Eval posture documented if using Tier 1 / Domain Admin shortcuts
• Production: Tier 2 or Tier 3 deployer + permission matrix
• Production: delegated AD join account (not Domain Admin) per delegation guide
• Production: Domain Admins disabled in Settings; dedicated admin group configured
• Appliance Owner password vaulted; break-glass procedure documented
• None of the three identities requires superuser by default

Related documentation