When you need it
Your pipelines deploy with cloud keys that were created years ago and never rotated. Copies sit in CI variables, on laptops and in old repositories, and nobody knows which ones still work.
What sets the quote
- One CI platform and up to 25 repositories that deploy to AWS, Azure or Google Cloud.
- Sized from counts you can pull yourself: cloud keys stored in your CI settings, IAM user access keys in the AWS IAM credential report, client secrets on Entra app registrations and Google Cloud service account keys.
- One to three weeks, depending on the number of repositories and clouds.
- More repositories, or a second CI platform, are quoted after the call.
What changes
- Pipelines reach your cloud with short-lived tokens instead of stored keys.
- Old keys are revoked, so a copy that leaked years ago no longer opens anything.
- Each pipeline can deploy only to the environments it is meant to reach.
- New secrets and vulnerable dependencies are caught at the pull request, before they reach production.
- Every gate has a decision record, so your team knows why it exists and when to change it.
What you get
- Inventory of long-lived keys, tokens and service account credentials, with last use where the cloud records it
- Federated trust between your CI platform and your cloud, set up as code
- Least-privilege deployment roles per repository and environment
- Revocation of old keys once their replacements are live
- Secret scanning in the pipeline and across your Git history, for example with Gitleaks or your platform's own secret scanning
- Dependency gates with agreed severity thresholds
- One decision record per gate
- Handover session and a runbook for adding new pipelines
What we cover on each cloud
| Area | AWS | Azure | Google Cloud |
|---|---|---|---|
| Trust | IAM OIDC identity provider for your CI platform | Federated identity credential on an app registration or user-assigned managed identity | Workload identity pool with an OIDC provider |
| Pipeline identity | IAM role per repository and environment, assumed with AssumeRoleWithWebIdentity | Service principal or managed identity, with Azure RBAC only on the resource groups or subscriptions it deploys to | Direct resource access for the federated principal, or service account impersonation |
| Scoped by | Trust policy conditions on the token’s audience and subject | The issuer and subject of each federated credential | Attribute mapping and an attribute condition on the provider |
| Keys retired | IAM user access keys | Client secrets and certificates on app registrations | Service account keys |
Not included
- Moving other secrets, such as database passwords or third-party API tokens, into a secrets manager (listed in the inventory and quoted separately)
- Keys used by running applications rather than pipelines
- Fixing the vulnerabilities the dependency gates find
- Rewriting Git history to remove old secrets (we revoke them instead)
What we need from you
- Admin rights on the repositories in scope and on your CI platform's secret and variable settings, for example Admin on GitHub or Maintainer on GitLab.
- AWS: permission to create IAM OIDC identity providers and IAM roles in the accounts in scope, directly or through your Terraform pipeline.
- Azure: Cloud Application Administrator in Entra ID, or Managed Identity Contributor for user-assigned managed identities, plus Role Based Access Control Administrator on the target scopes.
- Google Cloud: IAM Workload Identity Pool Admin and Project IAM Admin on the projects in scope.
- A developer from each team to confirm test deployments, about one hour per repository.
How it works
Free 30-minute call, then a written fixed quote based on your repository and key counts.
Scan repositories, CI settings and cloud IAM for long-lived keys, and record where each one is used.
Move each pipeline to federated tokens, one repository at a time, and test its deployments.
Revoke the old keys once nothing depends on them.
Switch on the scanning gates and write a decision record for each one.
At a glance
- Duration
- 1–3 weeks
- Price
- Fixed quote after a free 30-minute call
- Delivered by
- Our lead architect and a cloud engineer
Related work
Rayna Tours and TechnoHeaven
From one legacy account to a governed multi-account AWS platform
A multi-account AWS foundation for a travel group's twenty or so services, with guardrails, keyless pipelines and a temporary environment for every pull request, all defined in Terraform.
- 8
- AWS accounts in one organisation
- 40+
- Terraform repositories
Related services
DevSecOps gap check
In 1–2 weeks, a check of how your teams build and ship software, scored against OWASP SAMM and NIST SSDF, ending in a gap list and a 90-day plan.
Pipeline security check
A one-week review of one CI/CD platform, from organisation settings to runners and secrets, with findings mapped to the OWASP Top 10 CI/CD Security Risks and SLSA.
Secure CI/CD pipeline
A pipeline that scans every change, builds each image once, promotes it by digest and asks for approval before production, for one app in 2–3 weeks or up to 10 repositories in 4–5 weeks.