AWS CI/CD Integration Overview

minware can integrate with AWS as a source of CI/CD data. One integration reads three AWS services:

• CodeBuild — projects and builds
• CodePipeline — pipelines, pipeline executions, and action executions
• CodeDeploy — applications, deployment groups, and deployments

Rather than an access key, minware reads your account by assuming a read-only IAM role that you create. minware never holds a credential for your account: the role's trust policy names minware's ingest principal and requires an external ID that minware issues for your integration, and the role's permissions policy grants only list and read actions on the three services above.

Prerequisites

• You must be an organization admin in minware.
• You need permission to create IAM roles in each AWS account you want minware to read. If someone else manages IAM for your organization, you can hand them the setup files minware generates; they contain everything needed and do not require a minware login.
• Know the 12-digit account IDs and the regions you want minware to read. CodeBuild, CodePipeline, and CodeDeploy are regional services, so minware reads exactly the regions you list.

Connect in minware

1. In minware, go to Settings > Integrations
2. Under CI/CD, click AWS CI/CD
3. Enter each AWS account ID minware should read, and pick the regions to read in that account. Use Add another account for additional accounts. Each account should appear once, with all of its regions in the same entry.
4. Click Continue

minware creates the integration and issues its external ID. The next screen shows the accounts and regions you entered and a Download setup files button. Download minware-aws-setup.zip, which contains:

• README.md — the role name, your accounts and regions, the external ID, and step-by-step instructions for the AWS console, the AWS CLI, and Terraform
• trust-policy.json — the role's trust relationship
• permissions-policy.json — the role's read-only permissions

Click Done when you have the files, then follow the README in the bundle to create the minware-readonly role in each account. You can reopen this screen at any time from the integration's Setup button on the Integrations page, so the files can be downloaded again.

What Gets Ingested

For each account and region you listed, minware reads:

• CodeBuild: every project, and each build with its status, timing, and the commit it resolved
• CodePipeline: every pipeline, each pipeline execution with its status, timing, and source revision, and the action executions within each pipeline
• CodeDeploy: every application and deployment group, and each deployment with its status and timing

Builds, pipeline executions, and deployments are mapped into minware's standard CI/CD model of pipelines and pipeline runs, so they appear in the same deployment frequency, change failure rate, and CI/CD reports as your other CI/CD sources, and are queryable via minQL in any custom report. Every record carries the account and region it came from.

Where a build, execution, or deployment references a commit, minware links the run to that commit. Commit linkage requires the repository to also be connected to minware as a version control source. Today minware resolves repositories for GitHub-hosted sources: CodeBuild projects that build from a GitHub source, CodePipeline source actions connected to GitHub, and CodeDeploy revisions of type GitHub. A CodeDeploy deployment whose revision comes from S3 or an AppSpec is linked to its commit through the CodePipeline execution that triggered it, when that execution has a GitHub source.

Coverage and Limitations

• Read-only access. minware only ever lists and reads builds, pipelines, and deployments. The permissions policy contains no write, create, or delete actions, and minware cannot start, stop, or modify anything in your account.
• About 12 months of history. AWS limits CodePipeline execution history to the most recent 12 months and retains CodeBuild build history for 1 year, so the initial import covers approximately the last 12 months of builds and pipeline executions. Data minware has already imported is not removed when AWS ages it out, so history accumulates beyond that window over time.
• Exactly the regions you list. There is no default region. Builds, pipelines, or deployments in a region you did not list are not imported.
• Standard AWS partition only. Accounts in AWS GovCloud (US) or AWS China are separate partitions that cannot trust a principal in the standard partition, so they cannot be connected.
• One role name. The role must be named minware-readonly in every account. minware derives the role ARN from your account ID and cannot assume a role with any other name.
• Accounts and regions are fixed at setup. Editing the accounts or regions of an existing integration is not yet supported. If you need to change them, contact support@minware.com.
• No token to rotate. The integration has no access key or token. Its credential is the external ID minware issued, which does not expire, so the Update Token action does not apply to AWS integrations.

Troubleshooting

If the integration stays pending, or you do not see your CI/CD data in minware:

• Confirm the role exists in every account you listed and is named exactly minware-readonly.
• Confirm the trust policy's external ID matches the one in your setup files. You can reopen the setup screen from the Setup button on the Integrations page to check.
• Confirm the inline permissions policy was attached to the role.
• Confirm the regions you listed are the ones where your projects, pipelines, and applications actually live.

If you have done all of the above and still do not see your data, please contact us at support@minware.com.