Skip to content

Stateless Multi-Account Build System with AWS CodePipeline

Overview

TechSologic operates UnoLock with a stateless, multi-account CI/CD model built around AWS CodeCommit and AWS CodePipeline. The pipeline enforces branch protections, independent approvals, environment isolation, and staged promotion from development to test to production.

The goal is straightforward: deployment authority flows through controlled approvals, not direct account access.

UnoLock deployment targets are fully serverless, with no customer-managed servers or host OS instances, reducing host and network administration attack surface.

Pipeline Architecture

  • Source control in build account: UnoLock repositories are hosted in CodeCommit in a dedicated build account.
  • Developer workflow: Each developer works in a dedicated branch and can push only to that branch.
  • Protected master: Developers do not have write access to master.
  • PR-gated promotion: A pull request is required to promote changes toward deployment.

Deployment Flow

  1. A developer pushes commits to their own branch.
  2. The developer opens a pull request to master.
  3. Separate approvers with PR approval rights review and approve.
  4. Approval to master triggers a pipeline build and deploy to a separate AWS test account.
  5. The test environment is public at https://safe.test.1two.be and is used as a feature playground and broad validation target.
  6. A separate team has limited test-account access for troubleshooting.
  7. The pipeline includes an additional approval stage before production.
  8. A second approval is required for production promotion into a separate production account.

Security Controls in the Build System

  • No long-lived credentials: Build and operator access rely on temporary credentials, not static keys.
  • Identity hardening: Access to AWS Access Portal requires physical YubiKeys.
  • Centralized permissions: Identity and authorization are managed through IAM Identity Center and AWS Organizations.
  • Environment isolation: Build, test, and production run in separate AWS accounts.
  • Secrets handling: Build parameters are sourced from AWS Systems Manager Parameter Store (SSM), not committed to source.
  • Dependency control: Build dependencies are resolved through AWS CodeArtifact in the build account.
  • Default deny for new dependencies: New dependencies fail by default until explicitly approved and added to CodeArtifact.
  • Production access isolation: Developers, operations, and approvers do not have direct access to the production account.
  • Pipeline-only change path: No code or infrastructure changes are applied directly in accounts.
  • 100% Infrastructure as Code: Infrastructure updates are defined as code and deployed through pipeline-managed CloudFormation changes.
  • Single controlled deployment plane: Code deployment and CloudFormation deployment are both enforced through the same approval pipeline.
  • Multi-region deployment target: Pipeline promotions deploy runtime components across Canada and Ireland.
  • Multi-region resiliency components: UnoLock public endpoints, multi-region API Gateway (for API traffic), DynamoDB, and API-server root customer KMS keys are managed through the same controlled deployment process.
  • PITR policy: DynamoDB point-in-time recovery is configured for 7 days as part of the multi-region disaster recovery model.
  • Nightly dependency monitoring: A separate nightly security scan analyzes production npm lockfile dependencies (--omit=dev) for server, client, payments, serviceWorker, and EyesOnly.
  • Security reporting channels: Nightly scan outputs are written to S3 and summarized through SNS (with optional SQS fan-out and email subscription).

Why This Matters

Traditional CI/CD pipelines often fail at separation of duties, secret handling, or account segmentation. UnoLock's pipeline model is designed to:

  • keep deployment authority gated through independent approval,
  • prevent direct production manipulation by day-to-day contributors,
  • ensure consistent parameterized builds without embedding secrets in code,
  • reduce supply-chain risk through controlled dependency intake,
  • and enforce a single, auditable route for both application and infrastructure change.

FAQs

Can a developer deploy directly to production?

No. Developers can only push to their own branch and deploy in their own development account. Production promotion requires pipeline approvals and account-level isolation.

Where do build-time parameters come from?

Build parameters come from AWS SSM Parameter Store. Secrets and environment settings are not stored in source code.

How are dependencies controlled?

Dependencies are sourced from CodeArtifact in the build account. New dependencies are blocked by default until approved.

Can infrastructure be changed outside the pipeline?

No. Infrastructure and application changes are both controlled through the same CodePipeline approval flow and deployed as Infrastructure as Code.

How long are logs retained?

Application operational logs are retained for 3 days and are limited to error/trouble-detection data used for production troubleshooting, not user activity logging. Organization-wide AWS CloudTrail audit logs are configured in the parent account, stored in Amazon S3, and retained for 365 days. CloudTrail in this context is for TechSologic workforce/account access auditing, not customer application content.

How are newly disclosed dependency vulnerabilities monitored?

TechSologic runs a separate nightly lockfile vulnerability scan focused on production dependencies (npm audit --omit=dev --package-lock-only) for server, client, payments, serviceWorker, and EyesOnly. Reports are stored in S3 and summary alerts are distributed through SNS (and optional SQS/email subscriptions).

What is the recovery model for data?

UnoLock uses a multi-region recovery design. Individual-account recovery is not the target model; recovery procedures are designed for full multi-region disaster scenarios.

Integration with Other Features

  • Advanced AWS Account Management: Account-level identity and authorization boundaries enforce pipeline separation of duties.
  • Serverless Infrastructure: The pipeline deploys into isolated serverless environments across test and production accounts.