Managed OpenSearch now supports multiple SSO providers at once
Managed OpenSearch now trusts several identity providers at once. Employees, contractors, the company you just acquired and your CI pipelines all sign in through the system that already governs them, and the secrets behind it never leave the vault. SSO is still free on every tier.
Picture the Monday after an acquisition closes. Two hundred new colleagues, a different identity provider, and a shared logging cluster they all need by Wednesday. The old answer was a shared account, a second user list, or a directory merge that takes the rest of the year.
The new answer is a few lines of configuration, and they are in by lunchtime.
One cluster, as many identity providers as your business has
A cluster can now trust any number of providers, OIDC and SAML side by side. Each one is its own source with its own name and its own role mapping, and each one stays in charge of its own people.
- Acquisitions, day one. Bring the new team onto the shared cluster the week the deal closes. Merge directories later, on your schedule, or never.
- Contractors on their terms. External teams sign in through their own provider. You never create, track or chase up an account for someone you don’t employ.
- Provider migrations without the cutover weekend. Run old and new in parallel, move people across at your own pace, retire the old one when it’s empty.
- Least privilege that follows the org chart. Groups in your directory decide who sees what. Someone changes teams, their access changes with them.
And the offboarding story gets good. A leaver is disabled at the provider and can no longer sign in to the cluster. No ticket. No “did we remember the search cluster?”
On the Dashboards login page, people see a button for your OIDC provider, a button for your SAML provider, and the built-in operator account. They pick the one that’s theirs.
Your pipelines can stop carrying passwords
Humans aren’t the only users, and shared passwords love to hide in automation. So a source can be API-only: your CI job presents a short-lived token from your identity provider, and the cluster checks it against the provider’s published keys. No client secret to mint. Nothing to park in a pipeline variable. Nothing to forget to rotate.
The secrets we hold can’t leak, because they never come back out
The credentials you hand us to connect a provider are now write-only. They are stored encrypted, used by the cluster, and never returned by the API, the console or your Terraform state. All you ever get back is a simple “secret stored” flag.
That means a read-only token that escapes, a screenshot pasted into a support ticket, or an API response dropped into a chat can no longer expose your identity provider credentials. The same protection now covers the keys used for snapshot storage.
Your security team will like that one.
Set it up the way your team works
Use the console for the one-off, the API for tooling, and Terraform for the fleet. Same capability in all three. We wrote step-by-step guides for the providers most of you run, covering both the provider side and ours:
If you’re the one deciding how to roll this out, start with the SSO overview. It’s the short version of how the pieces fit.
Still free. On every tier.
Single sign-on is included at no additional charge, and so is every provider you add. Charging for the ability to secure your own account is not a business we want to be in.
Upgrading is a non-event
Clusters that already use OIDC or SAML are migrated automatically and keep working, secrets included. Teams that manage clusters with Terraform will see the configuration move to a single auth_sources list in the next provider release, and the Terraform documentation has the full reference.
Got a provider you want a guide for, or an identity setup you’re not sure fits? Write to [email protected] and tell us about it.