Why Your Redshift Users Should Never Have a Password
Stop handing out Redshift passwords. Here's how to use IAM Identity Center and get-cluster-credentials to give your analysts temporary, federated access that expires on its own.
At some point you gave a data analyst a Redshift username and password, they saved it in a sticky note on their monitor.
That was that.
Nobody mentions it because everyone has done it.
It works, technically.
But the moment you have ten analysts, a few contractors, and a shared BI tool connecting to production, you’re maintaining a list of database users that nobody fully owns, rotating credentials that break dashboards, and hoping that the person who left six months ago actually had their access revoked.
There’s a better model.
AWS has had get-cluster-credentials for years, and when you combine it with IAM Identity Center, you get something that actually solves the access management problem instead of just moving it around.
✔ Users authenticate through SSO
✔ IAM role calls Redshift for temporary credentials
✔ Credentials expire automatically.
⛔︎ No password spreadsheet.
⛔︎ No “hey can you reset my Redshift login” Slack messages.
The access is tied to their identity, and when they leave, deprovisioning their IdC account removes their Redshift access along with everything else.
I set this up for a data warehouse environment running on RA3 nodes, and the operational difference is real. But there are enough sharp corners in the implementation that I want to walk through what actually happens under the hood and where things go sideways.
What get-cluster-credentials Actually Does
The short version: it’s an API call that returns a temporary username and password for a Redshift cluster, valid for between 900 seconds and 3,600 seconds depending on how you configure the duration. Your application or BI tool uses those credentials to connect, and when they expire, it calls the API again. The credentials are short-lived by design.
The longer version involves understanding how Redshift handles IAM-mapped users.
When you call get-cluster-credentials, you pass a DbUser parameter that tells Redshift which database user to authenticate as. If that user doesn’t exist in the cluster, you can pass AutoCreate: true and Redshift creates it on the fly. The user that gets created is prefixed with either IAM: or IAMR: depending on whether the credential was generated from an IAM user or an IAM role. So a call made via a role named redshift-analyst creates a database user called IAMR:redshift-analyst.
This prefix matters for a couple of reasons.
First, it’s how you manage permissions inside Redshift. You grant access to schemas, tables, or schemas to IAMR:redshift-analyst the same way you’d grant it to any other user.
Second, it’s how you can scope IAM policy to prevent someone from using DbUser to impersonate another user’s role. The redshift:DbUser IAM condition key lets you write a policy that says “this role may only request credentials for this specific DbUser value.”
Without that condition, a sufficiently clever person with the role could request credentials as a more privileged database user. Add it to your policies.
The IAM permission itself is redshift:GetClusterCredentials, and it goes on the role that your IdC permission set grants. The resource ARN is specific: it includes both the cluster identifier and the DbUser, which means you can write narrow policies that only allow credential generation for specific clusters and specific database user names.
That granularity is worth using.
Where IAM Identity Center Comes into the Picture
IAM Identity Center doesn’t change how get-cluster-credentials works at the Redshift layer. What it changes is how users get the IAM role that makes the call.
Without IdC, you might have IAM users with long-term credentials calling the API directly, or you might be managing role assumptions manually.
With IdC, your users:
authenticate to AWS through SSO
get a short-lived role session via their assigned permission set
have a session including the
redshift:GetClusterCredentialspermission
The whole thing is federated. The user never touches an IAM access key. Huge win.
The permission set in IdC needs the redshift:GetClusterCredentials action, scoped to the cluster and DbUser ARNs you want that group of users to access.
Something like:
{
"Effect": "Allow",
"Action": "redshift:GetClusterCredentials",
"Resource": [
"arn:aws:redshift:us-east-1:123456789:dbuser:your-cluster/IAMR:analyst-role",
"arn:aws:redshift:us-east-1:123456789:dbname:your-cluster/analytics"
]
}
You also need the redshift:DbUser condition key if you want to prevent users from requesting credentials for a DbUser they shouldn’t have access to.
I’d add it by default.
The extra five minutes of policy writing saves a real conversation later.
One thing I learned the hard way: the database user that IdC-federated sessions create depends on the role session name, which is derived from the IdC user’s identity. If your permission set is assigned to a group, all members of that group get the same role, which means they all get the same DbUser prefix in Redshift unless you’re doing something more sophisticated.
For most analytics use cases this is fine.
For audit requirements where you need individual user attribution in Redshift query logs, you’ll want to think about whether group-level roles give you enough granularity. The Redshift query logs will show the IAMR: prefixed user, not the individual’s name, unless you’ve designed the permission sets to map one-to-one per user.
Connecting a Tool like DBeaver to This
Most analysts aren’t calling get-cluster-credentials from the CLI. They’re connecting through a SQL client, usually DBeaver or a BI tool.
Here’s where it gets mildly annoying.
DBeaver supports IAM authentication for Redshift natively. In the connection settings, you choose the IAM auth type, configure your AWS profile or role, and DBeaver handles the credential call under the hood. It will invoke get-cluster-credentials using your local AWS credentials and pass the resulting temp username and password to the Redshift JDBC driver.
The profile needs to resolve to credentials that have the redshift:GetClusterCredentials permission. If the user is authenticating through IdC, they need the AWS CLI’s SSO login flow set up so their local profile has a valid session.
Running aws sso login --profile your-profile before opening DBeaver is the current experience.
It’s not terrible once the profile is configured, but it’s a step that needs to be in your onboarding documentation, because users who haven’t done it before will open DBeaver, try to connect, and get an authentication error with no obvious explanation.
The temp credentials also expire mid-session if the connection is held open long enough. DBeaver will usually handle reconnection automatically, but some BI tools do not. Know your tooling.
What This Doesn’t Solve
Temporary credentials don’t eliminate the need to manage database-level permissions inside Redshift.
The IAMR: user still needs GRANT statements for the schemas and tables it should access. AutoCreate will make the user exist, but it won’t give that user any permissions beyond whatever the default group gets. If your default group has no permissions, a freshly created IAM-mapped user will connect successfully and then see nothing.
The operational pattern that works: create a role or group inside Redshift for each access tier you care about, and GRANT that group’s permissions to the IAMR: prefixed user on creation. You can automate this with a stored procedure that fires on new user creation, or manage it as part of your database provisioning scripts. Either way, “user can authenticate but can’t see any data” is a support ticket that will absolutely come in if you don’t handle this upfront.
There’s also the question of what happens in a multi-account architecture.
If your Redshift cluster lives in account A and your users authenticate through IdC in account B, the role assumption crosses account boundaries. That’s solvable with cross-account roles and trust policies, but it adds configuration surface area. The permission set in IdC needs to assume a role in account A that has the redshift:GetClusterCredentials permission, which means you’re managing a trust relationship between the IdC role and the target account’s role.
It works, and it’s the right architecture for a proper multi-account setup, but don’t underestimate the number of IAM policies involved.
Honest assessment: this is more initial setup than username/password.
The ongoing operational simplicity is genuinely better, especially at scale, but the upfront configuration is nontrivial and the tooling for SSO-connected analysts requires real onboarding.
If you have five analysts who are comfortable with the AWS CLI and DBeaver’s IAM mode, this is a clean win.
If you have thirty analysts who are not AWS-fluent, plan for the onboarding overhead and make sure your documentation is clear before you deprecate the old password-based access.
Have you ever tried using AWS IAM Identity Center to provision access amongst your organization?
I’d love to hear about it in the comments!
With Love and DevOps,
Maxine
If this kind of infrastructure detail is useful to you, both of my learning resources are built for engineers who want to understand systems this deeply.
LLMs for Humans: From Prompts to Production covers how language model systems are actually built and deployed, from token mechanics to production architecture, written for engineers who want to use them rather than just talk about them.
The DevOps Career Switch Blueprint covers the AWS and IaC foundations that make setups like this make sense when you’re building the career to go with the knowledge.
I Love DevOps, is where I write about production systems the way engineers actually encounter them.
Last Updated: March 2026