Security model

The Hub installs software into your AWS account, so in Full mode it holds a role with broad permissions. This page describes what runs where, who may use the Hub, every role it creates and what each may do, and the data it keeps. It is written for security reviewers; every statement here is enforced by the Hub's template or its code.

#Everything runs in your account

The Hub is one CloudFormation stack in your account. Its API, web app, sign-in, settings and audit log all live there, and nothing it holds is sent to Cloud Certainty.

From outside your account it reads only public files:

• Cloud Certainty's product catalogue (CatalogueUrl);
• each product's latest.json release manifest, and the Hub's own;
• the products' and the Hub's CloudFormation templates, from Cloud Certainty's release buckets.

Everything else it reads is AWS APIs in your own account: CloudFormation, AWS Marketplace agreements, EC2 networks, IAM Identity Center, Cognito and Secrets Manager.

#Who may use the Hub

People sign in with the Hub's identity provider (IAM Identity Center, SAML, OIDC or Cognito users), and the Hub's API accepts only signed-in requests. A signed-in person must also have a trusted email: always with SAML, and with Cognito and OIDC only when the email is verified.

Only Hub administrators may do anything other than see who they are. Everyone else is refused. Administrators are:

• the BootstrapAdminEmail;
• the emails in the Hub's Settings;
• members of the groups in Settings;
• members of the CloudCertaintyHubAdmins group in IAM Identity Center.

In Full mode, Hub administrators can create and change AWS resources through the deployer role, so treat them as AWS administrators of the account.

Sessions use one-hour tokens, refreshed for up to eight hours. Cognito users must use an authenticator app.

#Roles the Hub creates

Every role name starts with the Hub's NamePrefix (cc-hub by default) and ends with the Region.

#The deployer role and Full mode

In Full mode the Hub runs product stacks with a CloudFormation service role, the deployer role. It is trusted only by CloudFormation, only on behalf of your account, and its permissions cover the resource types the products create (IAM roles and policies, Lambda, API Gateway, Cognito, Amplify, DynamoDB, S3, KMS, CloudWatch Logs, SNS, EventBridge, ECS, EC2 security groups and VPC endpoints, Step Functions and Athena, with read access to Secrets Manager, Systems Manager parameters and License Manager). Apart from IAM and reading templates, its permissions are limited to the Hub's Region.

The deployer role cannot touch the Hub:

• it is denied every IAM action on the Hub's roles;
• it is denied every DynamoDB and Lambda action on the Hub's table and functions.

The Hub's API can use the deployer role only on stacks whose names start with StackNamePrefix (cc- by default) and only for change sets named cc-hub-*; IAM enforces both. The Hub's code adds one more check: it changes only stacks tagged cloudcertainty:managed-by=hub, and never one managed by Terraform or installed another way. Every install and update is a change set that an administrator reviews before it runs; deleting a stack asks for its name to be typed.

With DeployMode set to ExportOnly, there is no deployer role, and the Hub cannot create, update or delete any product stack.

#The self-update role

The Hub updates itself with a separate CloudFormation service role. It can change only the Hub's own resources: roles, functions and log groups whose names start with NamePrefix, the Hub's table and artifacts bucket, its user pool, HTTP API and Amplify Hosting app, and its update topic and schedule.

The Hub's API may create a change set on its own stack only:

• with the self-update role;
• with a template from the Hub's release bucket, https://cloudcertainty-hub-us-east-1.s3.us-east-1.amazonaws.com/<version>/main.yaml;
• named cc-hub-self-*.

IAM denies any other change set on the Hub's stack, and denies DeleteStack and UpdateStack on it outright. The Hub never deletes itself, and it never updates itself when Terraform manages it.

#Templates only from Cloud Certainty

The Hub installs a product only from the template URL in that product's latest.json, and its roles may read templates only from Cloud Certainty's release buckets (cloudcertainty-*-us-east-1). It updates itself only from the Hub's own release bucket. Release folders are immutable: a published version never changes.

#Names

Every resource the Hub creates for itself starts with NamePrefix, cc-hub by default: cc-hub-api, cc-hub-table, cc-hub-users and so on. So do the things it creates while it works:

• change sets: cc-hub-<time> on product stacks and cc-hub-self-<time> on its own stack;
• sign-in clients for products: cc-hub-<stack name> in the Hub's user pool;
• their secrets: cc-hub-<stack name>-oidc-client in Secrets Manager.

Product stacks it installs start with StackNamePrefix, cc- by default, and are tagged cloudcertainty:managed-by=hub, cloudcertainty:product and cloudcertainty:hub.

#Data, encryption and logs

• Settings and audit log: a DynamoDB table, <NamePrefix>-table, with point-in-time recovery. It holds the Hub's settings, the IAM Identity Center it manages, the update reminder state, and an audit entry for every change (settings, change sets, stack deletions, IAM Identity Center changes, sign-in clients, Hub updates), kept for 400 days. Every audit entry is also a JSON line in the Hub's CloudWatch logs.
• Code: the Hub copies its release's code into a private S3 bucket in your account, with public access blocked and HTTPS required.
• Encryption: with KmsKeyArn set, your KMS key encrypts the table, the log groups, the artifacts bucket and the update topic. Without it, the table uses an AWS owned key, the bucket SSE-S3, and the topic the AWS managed key for SNS.
• Logs: the Hub's CloudWatch log groups keep LogRetentionDays days (90 by default).
• No secrets in exports: secret parameters are never written into a Terraform or CloudFormation export.