On this page · 11 sections
- What AWS shipped, and what it did not say
- Who this rules out
- The two rotation architectures, and where the admin token bites
- The Okta discrepancy
- What it costs, and what the pricing page does not itemise
- What to do this week
- India-specific considerations
- What is still unknown
- FAQ
- How eCorpIT can help
- References
Summary. On 11 August 2026 AWS extended Secrets Manager managed external secrets to two new secret types, JenkinsApiToken and SonarQubeToken, so CI/CD credentials rotate without a custom Lambda function. The announcement describes console-driven rotation "without writing any custom rotation code". The Secrets Manager User Guide adds a sentence the announcement omits: "Instances that are not reachable over the public internet are not supported." Rotation traffic originates from the AWS-managed prefix list com.amazonaws.<region>.secretsmanager-managed-external-secrets, and your instance must present a publicly trusted TLS certificate. Secrets cost $0.40 per secret per month and $0.05 per 10,000 API calls in both us-east-1 and ap-south-1, and managed rotation adds no Lambda charge. The announcement also lists Okta as an existing partner; Okta appears nowhere in the user guide's partner table, which carries 14 secret types across 11 vendors.
What AWS shipped, and what it did not say
Managed external secrets is a Secrets Manager secret type that stores third-party credentials in a format each partner defines and rotates them through a driver AWS operates. No Lambda function is deployed in your account. The 11 August 2026 What's New entry adds Jenkins API tokens and SonarQube tokens to that list and frames the benefit in operational terms: for Jenkins, "Secrets Manager mints a new token and revokes the old one only after the replacement is verified active, so your continuous integration and continuous delivery (CI/CD) jobs transition without interruption."
That claim holds. The rotation sequence in the Jenkins API Token page is specific: the driver validates the current token, obtains a Cross-Site Request Forgery crumb from Jenkins, generates a new API token, stores it as the pending version, verifies the new token against the Jenkins API, promotes it to current, and only then revokes the old token by its tokenUuid. There is no window where both tokens are dead.
The network requirement is the part that decides whether any of this applies to you. Both partner pages carry the same paragraph, and it is worth reading in full because it is the whole article. From the AWS Secrets Manager User Guide: "Jenkins is customer-hosted, so your Jenkins instance must be reachable over HTTPS from the Secrets Manager rotation service. Rotation calls originate from the AWS-managed prefix list com.amazonaws.{{region}}.secretsmanager-managed-external-secrets. Allow inbound access from this prefix list on your instance's security group or firewall, and ensure the instance presents a publicly trusted TLS certificate. Instances that are not reachable over the public internet are not supported."
The SonarQube Token page repeats it verbatim for SonarQube Server.
Who this rules out
Most Jenkins controllers that hold production deploy credentials are not on the public internet. They sit in a private subnet, behind a VPN, or in an on-premises data centre reachable only over Direct Connect or a site-to-site tunnel. For those installations the feature is not "harder to configure". It does not work at all, because the rotation driver initiates the connection from AWS-owned address space toward your endpoint.
Three details make the exposure decision sharper than a normal allowlist:
The prefix list is regional. It is named per Region, so a secret in ap-south-1 uses com.amazonaws.ap-south-1.secretsmanager-managed-external-secrets and a secret in us-east-1 uses the us-east-1 name. If you replicate secrets across Regions you are allowlisting more than one range.
The ranges move. The Security and permissions page tells you to use the managed prefix list precisely because "using the managed prefix list ensures your ingress rules automatically stay current as the underlying IP ranges change", and if you resolve it programmatically through GetManagedPrefixListEntries you "should periodically refresh your ingress rules with this prefix list to keep them current". A one-off copy of the CIDRs into a corporate firewall is a future outage.
The certificate must be publicly trusted. An internal CA that every one of your build agents trusts is not enough. The URL must also use HTTPS with no trailing slash, which the field descriptions state explicitly for both jenkinsUrl and sonarqubeUrl.
| Deployment | Rotation works? | What you would have to change |
|---|---|---|
| Jenkins on a public EC2 instance with an ACM or Let's Encrypt certificate | Yes | Add prefix-list ingress on 443 |
| Jenkins in a private subnet behind an internal ALB | No | Publish a public HTTPS endpoint |
| Jenkins on-premises reachable only via Direct Connect or VPN | No | Publish a public HTTPS endpoint |
| Jenkins behind a corporate proxy with an internal CA | No | Replace with a publicly trusted certificate |
| SonarQube Server in a private VPC | No | Publish a public HTTPS endpoint |
| SonarCloud or other vendor-hosted SaaS | Not covered | The partner pages describe customer-hosted servers only |
Setting aside the network path, the credential model is tighter than most home-grown rotation scripts. AWS states that managed external secrets "does not require you to share admin-level privileges of your third party application accounts with AWS", and rotation runs under an IAM role you provide.
The two rotation architectures, and where the admin token bites
Both partners support self-rotation and admin-assisted rotation, selected by whether you set the optional adminSecretArn metadata field. Omit it and the current token authenticates its own replacement. Provide it and a separate admin token generates and revokes the target token.
For SonarQube the choice is not always yours. The tokenType field takes USER_TOKEN (the default), GLOBAL_ANALYSIS_TOKEN, or PROJECT_ANALYSIS_TOKEN, and the user guide states that adminSecretArn "is required for Global Analysis and Project Analysis tokens. It is optional for User Tokens". Analysis tokens are exactly the ones CI pipelines use, so most teams end up storing a long-lived SonarQube admin token in a second Secrets Manager secret and granting the rotation role access to it. That secret is now the highest-value credential in the chain, and nothing rotates it.
PROJECT_ANALYSIS_TOKEN also requires the projectKey field, which means one secret per project rather than one secret per pipeline.
| Field | Jenkins JenkinsApiToken |
SonarQube SonarQubeToken |
|---|---|---|
| Credential field | apiToken, a 32-34 character hexadecimal string |
token, prefixed squ_, sqa_ or sqp_ |
| Revocation handle | tokenUuid, updated after each rotation |
tokenName, unique per user |
| Owner field | username |
login |
| Endpoint field | jenkinsUrl, HTTPS, no trailing slash |
sonarqubeUrl, HTTPS, no trailing slash |
| Admin secret | Optional; omit for self-rotation | Required for Global and Project Analysis tokens |
| Extra field | None | tokenType, plus projectKey for project tokens |
The Okta discrepancy
The What's New post says the two new integrations "join existing managed external secrets support for BigID, Confluent Cloud, Datadog, GitLab, MongoDB Atlas, Okta, Paddle, Salesforce, and Snowflake."
The user guide's Integration Partners table lists BigID, Confluent Cloud, Datadog (three secret types: API key, application key, admin key), GitLab, Jenkins, MongoDB Atlas (service account and database user), Paddle, Salesforce, Snowflake (key-pair authentication and personal access token), and SonarQube. That is 14 secret types across 11 vendors. Okta is not among them, and a search of the guide's full table of contents returns no Okta page at all as of 22 August 2026.
Either the documentation is behind the launch or the announcement names a partner that has not shipped. If you are planning a rotation programme around Okta API tokens, confirm the secret type exists before you write the runbook. The secretsmanager:resource/Type condition key in the example permissions policy is scoped to a named secret type, so a type that does not exist cannot be granted.
What it costs, and what the pricing page does not itemise
Secrets Manager bills on stored secrets and API calls. Reading the current values from the AWS pricing metering data on 22 August 2026: a secret costs $0.40 per secret per month, and API requests cost $0.000005 each, which the pricing page states as $0.05 per 10,000 API calls. Both figures are identical in US East (N. Virginia) and Asia Pacific (Mumbai), so an Indian team pays roughly ₹35 per secret per month at 88 rupees to the dollar. A replica secret in a second Region is billed as a distinct secret.
There is no separate line item for managed external secret rotation. The Secrets Manager introduction is explicit that the Lambda charge applies "when you turn on automatic rotation (except managed rotation)", and the managed external secrets page confirms that "no Lambda functions deployed in your account". A team replacing ten hand-written rotation Lambdas removes ten functions, ten sets of VPC configuration, and ten pieces of on-call surface for $4.00 a month in secret storage.
That is the honest win here. The rotation code was never the expensive part; the maintenance of ten bespoke Lambdas was.
What to do this week
Check reachability before anything else. From outside your network, resolve and open https://<your-jenkins-url> and inspect the certificate chain. If it does not resolve publicly, or the chain terminates at an internal CA, stop. This feature is not available to you and no amount of IAM work changes that.
If it does resolve, add ingress from the regional prefix list rather than hard-coded CIDRs, and confirm the URL has no trailing slash. Then create the secret with CreateSecret, setting the secret type to JenkinsApiToken or SonarQubeToken, and configure rotation with RotateSecret, passing the rotation role ARN.
The rotation role needs four Secrets Manager actions (DescribeSecret, GetSecretValue, PutSecretValue, UpdateSecretVersionStage) plus GetRandomPassword, with a trust policy allowing secretsmanager.amazonaws.com to assume it under aws:SourceAccount and aws:SourceArn conditions. AWS scopes the console-generated role to one partner in one Region, which is the right default; if you build the role yourself, keep the secretsmanager:resource/Type condition rather than widening it.
Finally, make consumers read through the caching library. Both partner pages note that applications using the Secrets Manager caching library "pick up the new token on their next refresh". A pipeline that bakes the token into an environment variable at container build time will keep using a revoked credential until the next build. That failure looks like a Jenkins authentication error hours after a successful rotation, and it is the one most teams hit first. Teams standardising this across many pipelines usually fold it into their release engineering and CI/CD platform work rather than patching job by job.
India-specific considerations
Indian engineering teams running Jenkins in ap-south-1 face the same public-reachability rule, and it interacts badly with a common pattern: a Mumbai VPC with no internet gateway, build agents reaching AWS services through VPC endpoints, and the controller published only to an internal load balancer. That design is often chosen deliberately for Digital Personal Data Protection Act 2023 posture, because it removes an internet-facing attack surface from a system that can read source code and deploy to production.
Publishing that controller to satisfy a rotation feature is a trade, not an upgrade. Before making it, price the alternative: a self-managed rotation function inside the VPC costs Lambda invocations plus the engineering time to maintain it, and it keeps the controller private. For most teams with a private Jenkins, keeping the private controller and writing the rotation is still the better answer.
What is still unknown
AWS says the feature is "available in all AWS Regions where AWS Secrets Manager managed external secrets is supported", and neither the announcement nor the user guide publishes that Region list. There is no stated rotation timeout, no documented behaviour when the endpoint is unreachable mid-rotation, and no published quota on managed external secrets per account. The Okta question is open. Until AWS publishes a Region table, treat availability as something to test in your own account rather than something to plan a rollout against.
FAQ
How eCorpIT can help
eCorpIT is a CMMI Level 5 and ISO 27001:2022 certified engineering organisation in Gurugram that builds and runs CI/CD platforms for teams on AWS. Our senior engineering teams assess whether managed external secrets fits your Jenkins and SonarQube topology, or design an in-VPC rotation path when publishing the controller is not an acceptable trade. That work sits alongside our wider DevOps services and the IAM hardening we cover in our note on the IAM role manager's PowerUserAccess default. To review your secret rotation posture, contact us at /contact-us/.
References
- AWS Secrets Manager adds managed external secrets support for Jenkins and SonarQube, AWS What's New, 11 August 2026
- Using AWS Secrets Manager managed external secrets to manage Third Party secrets, AWS Secrets Manager User Guide
- Jenkins API Token, AWS Secrets Manager User Guide
- SonarQube Token, AWS Secrets Manager User Guide
- Managed external secrets Partners, AWS Secrets Manager User Guide
- Security and permissions, AWS Secrets Manager User Guide
- Rotate Secrets Manager managed external secrets, AWS Secrets Manager User Guide
- What is Secrets Manager? Pricing section, AWS Secrets Manager User Guide
- AWS Secrets Manager Pricing, AWS, retrieved 22 August 2026
- CreateSecret, AWS Secrets Manager API Reference
- RotateSecret, AWS Secrets Manager API Reference
- GetManagedPrefixListEntries, Amazon EC2 API Reference
- Work with AWS-managed prefix lists, Amazon VPC User Guide
Last updated: 22 August 2026.
