Infrastructure Changes

saferatday0 team

What are we talking about?

• IT needs overall security and visibility

• Infra team need to manage delivery environments

• Project teams need to be able to deploy apps

• Portability matters for open source

• New funding sources increase compliance burden

What's coming?

• DSRI is moving to AWS

• ul.org accounts for cloud access

• Greater IT involvement in supporting DSRI

• Billing consolidation for shared services

• Stricter guardrails and monitoring (e.g. Crowdstrike)

• Managed Linux endpoints

What's going away

• DSRI management of top-level cloud environment

• Most Google Cloud projects

• "DSRI Cloud" as environment separate from IT

• Personal accounts for open source work

What's not going away

• dsri.org email accounts

• Google Workspace

• Other DSRI services*

*but we should probably switch to Teams

Top-level AWS organization

Top-level AWS organization

• Infrastructure OU provides shared services

• Security OU provides top-level security features

• Workload OU provide deployment environments with differing readiness levels and baselines

Typical AWS deployment

Typical AWS deployment

• DSRI systems live in AWS accounts managed by IT

• Single AWS account per project per environment

• IT owns overall governance

• DSRI owns everything inside accounts

• Organization-wide compliance guardrails

• Account-level IAM access to manage deployments

Typical AWS deployment (IT view)

Typical AWS deployment (IT view)

IT provisions:

• Organization hierarchy, billing, reporting (AWS Organizations)

• Organization-wide IAM (AWS SSO)

• Organization-wide policy (Service control policies, organization roles)

• Organization-wide infrastructure

  • Logging, audit trail (AWS CloudTrail)

  • Compliance (AWS Config)

  • Security, monitoring (AWS GuardDuty, AWS Security Hub)

Typical AWS deployment (infra view)

Typical AWS deployment (infra view)

Infra teams provision:

• Account-level IAM (service accounts, assumable roles)

• Account-wide infrastructure

  • Network (VPCs, firewalls, gateways, load balancers)

  • Storage (Managed databases, block storage, object storage)

  • Compute (Kubernetes clusters, EC2 instances, serverless functions)

• Cluster-wide resources

  • Ingress, service mesh, certificate management, backup

Typical AWS deployment (project view)

Typical AWS deployment (project view)

Project teams provision:

• Minimal footprint limited to specific application

• Runs in constrained cluster footprint for local testing

• Limited exposure/visibility into non-portable cloud functionality

• Apps run everywhere containers run

• Infra/app responsibility split varies on case-by-case basis

IAM principles

• Organization-level (AWS) IAM provisions teams

  • Managed by IT

• Account-level (AWS) IAM provisions platforms

  • Managed by infra team

• Cluster-level (Kubernetes) IAM provisions applications

  • Managed by project team

Cloud transition roadmap

• IT builds AWS cloud organization

• Infra builds cloud account baseline

• Projects transition to AWS

• Infra reduces to minimal GCP footprint

Project transition roadmap

• Phase 0: Identify architecture

• Phase 1: IT deploys organization accounts

• Phase 2: Infra deploys cloud resources

• Phase 3: Project AWS deployment and verification

• Phase 4: Final data migration and verification

• Phase 5: Tear down old application instance

Project transition order

• DSID

• Shared (formerly "Data")

• Dyff

• SemaFor