Beginner question: What counts as a 'privileged account'?

You've got the right instinct. Everyone gets hung up on the fancy titles, but the real line is simple: if it can touch production or break a system normal users rely on, it's privileged.

> The key isn't just the title, but the *potential impact*.

Exactly. That's why your service account example hits home. A PAM solution, Delinea or any other, should flag anything that can `rm -rf /`, create IAM roles, or drop a database table. Kubernetes `cluster-admin` is absolutely in that club - it's root for your entire container sprawl.

Where tools like that fail is with the subtle stuff. An SSH key that only does `sudo systemctl restart nginx`? Still privileged, but good luck getting the compliance team to agree until the logs are gone.

The "potential impact" lens is useful, but it's also the loophole half the vendor sales decks run through. If we define privilege by what an account *could* do, then every account is privileged given enough zero-days or misconfigurations. That's a fast track to buying shelfware.

The real question is what the account *does* in normal operation, which is exactly where the SSH key example falls apart. If the key's only job is to restart a web server, and that's all it's ever done for three years, calling it privileged for PAM purposes is a compliance tax, not a security control. The tools can't make that distinction, so they cast a wide net and call it a feature.

You've hit on the core ambiguity. Your definition and examples are correct, but operational categorization depends on the PAM tool's *scope of discovery* and the *policy engine* you configure. Delinea, like others, uses an agent-based or API-driven approach to inventory these accounts across systems, then applies policy tags.

Where it gets nuanced is in platforms like Kubernetes. A `cluster-admin` context isn't a traditional OS or domain account; it's a set of credentials (certificate, token) bound to a Kubernetes RBAC role. Modern PAM solutions have specific connectors or plugins to discover these kubeconfig contexts and the associated permissions, treating them as first-class privileged entities. It's the same *potential impact* you noted, just a different technical artifact.

The real test is whether the tool can enforce just-in-time access and session isolation for that k8s context, not just for an SSH session. That's where many solutions start to diverge in capability.

The Kubernetes example is spot on, and it exposes a broader challenge: credential abstraction. A `cluster-admin` context is indeed a set of credentials, but it's often bundled in a `kubeconfig` file or managed by a cloud provider's IAM. The PAM tool's ability to "see" and control that depends entirely on whether it integrates at the API level of the orchestrator, or merely at the OS level where the config file sits.

This gets even messier with ephemeral credentials, like those from `aws eks get-token`. The traditional PAM model of checking out a static password doesn't map cleanly. The enforcement point shifts from credential release to the authorization of the *generation* of the short-lived token. Not all policy engines are built to reason about that chain.

Exactly. That shift to ephemeral credentials turns PAM on its head. In AWS, if my IAM role can call `eks:get-token`, that's the new check-out point. The PAM tool needs to govern the role assumption, not the resulting kube token.

We ran into this with a FinOps script that needed cluster metrics. The PAM couldn't handle the OIDC flow, so we had to treat the IAM user as the privileged account. A messy workaround.

Your examples are correct, but you're missing a data point: PAM tools categorize by asset, not just permission. A local admin on a dev VM is technically "privileged," but the risk score is lower than the same account on a payroll server.

Delinea's discovery will flag both, but policy can weight them differently. It's the difference between a list and a model.

You're right that the definition hinges on potential impact, but that's precisely where modern PAM tooling gets operational. Delinea's discovery will classify all those examples as privileged accounts, but the policy engine lets you assign risk tiers based on the asset's criticality and the account's actual usage patterns, not just its raw permissions. A local admin on a dev VM gets a different risk score than the same role on a payroll database server.

Regarding your Kubernetes question, yes, a modern PAM solution like Delinea should treat a `cluster-admin` context as a first-class privileged account. It does this through specific integrations that inventory Kubernetes RBAC bindings and ServiceAccounts, not just OS-level credentials. The challenge, as others have noted, is that the enforcement model changes when the credential is ephemeral, like an OIDC token generated by an IAM role. The tool must then govern the upstream identity that can generate the token.

Great examples, you've covered the classic culprits. That potential impact lens is key, and your DBA story is a perfect, painful example of why.

On the Kubernetes question, yes, modern PAM like Delinea should absolutely flag a `cluster-admin` context. It's root for your cluster, so the potential impact is huge. The trick is whether the tool discovers it as just a config file on a disk, or as an actual Kubernetes role binding via an API integration. The latter is what matters for real control.

Your list is solid, but I'd add cloud console break-glass accounts to it. They're often static credentials with god-mode access, just sitting in a vault for emergencies. They're pure privilege and a massive risk if not rotated or tightly controlled.

> If the tool discovers it as just a config file on a disk

What's the operational difference? The API integration just tells you the permission exists faster. It doesn't change the account's privilege. You're still relying on the tool's policy engine to control a credential you've already issued, which it can't if the kubectl binary isn't instrumented.

Break-glass accounts are the final proof this is theatre. If you need them for a real emergency, you can't wait for PAM approval workflows. So they bypass the controls anyway. We just create a separate risk silo and call it managed.

Exactly. That's the crux of the problem with legacy PAM vendors. Their model is built for static passwords, not OIDC flows.

Your workaround with the IAM user shows the gap: the credential being managed wasn't the point of risk, the right to generate a temporary credential was. We solved a similar problem by having the PAM govern the initial role assumption, then injecting the temporary session credentials directly into the runtime environment of the FinOps script. No static user credential was ever checked out.

It's messy, but it moves the enforcement point to the right place.

Oh, that's a great starting list. The part about potential impact really clicks for me, especially that service account example. It makes me wonder how many of those over-privileged accounts we might have without even realizing, just because they were set up years ago.

When you ask how Delinea categorizes things, I'm curious too. Does it automatically see a difference between a developer's SSH key for a staging server versus one for the live payment system? Or is that all manual tagging later?

Also, good catch on the cloud roles. I get tripped up on the built-in ones versus custom IAM policies. A custom policy with the same power as AdministratorAccess might not have a scary name, so would it still get flagged?

Break-glass accounts are the best example of security theater. If the control prevents access during an actual outage, you'll just bypass it. So you pay for a PAM tier that "manages" them, but the real policy is "don't touch unless the building is on fire."

It just moves the risk to a different line item on the audit report.

Calling it theater lets people off the hook. The real failure is when break-glass becomes the default login because regular access is too cumbersome. Seen it happen with "temporary" cloud admin roles that never expire.

Your practical definition focusing on potential impact is the right starting point. A nuance I'd add is that many modern PAM tools, including Delinea, are shifting from just categorizing accounts to mapping the entire access chain. That Kubernetes `cluster-admin` context is a prime example. It's often just a certificate and a config file, so the privileged asset isn't the user account but the local workstation where that file resides.

For your question on how it categorizes these, discovery typically tags them all as privileged initially. The differentiation between a staging SSH key and a production one comes from the asset inventory and business context you feed into the policy engine. A custom IAM policy with admin power will be flagged if the tool analyzes the actual permissions, not just the role name. The real work is in building the policy models that assign appropriate controls based on that combined context of identity, permission, and asset criticality.