Why most Snowflake service users are ticking time bombs (and how to defuse them)

Somewhere deep in your Snowflake account, a user quietly runs daily ETL jobs, powers dashboards, or syncs data to external systems. You know this user is crucial, but you’ve never actually met them. Because in Snowflake, that user isn’t a person — it’s a service user.

Managing these service users well is one of those behind-the-scenes tasks that can make or break your security posture and operational reliability. Yet, it’s easy to overlook or mess up. How do you create one that’s secure without breaking your workflows? How do you keep track of what it’s doing? And how do you make sure it stays locked down like a vault, even as your environment changes?

I once walked into a situation where a service user had been granted SYSADMIN privileges simply so some automation would run without errors. That user had access to everything. It was a ticking time bomb. This post is about setting up Snowflake service users thoughtfully, balancing access, security, and manageability.

Creating a Service User with Minimal Privileges

Snowflake’s CREATE USER command lets you spin up a user easily. But the key is not just to create the user, but to assign the least privilege necessary.

Think of this like giving someone the keys to only the rooms they actually need to enter, not the whole building. A service user rarely needs SYSADMIN or ACCOUNTADMIN rights. Instead, create a custom role tailored to its specific job and assign just that.

Here’s how you create a basic service user with a strong password and minimal default privileges:

-- Create a service user with a strong password and assign only the necessary role
CREATE USER service_user
  PASSWORD = 'StrongPassword123!'
  DEFAULT_ROLE = 'PUBLIC'
  MUST_CHANGE_PASSWORD = FALSE;

-- Grant minimal required privileges to the service user
-- Avoid granting SYSADMIN role as it is a powerful role
-- Instead, create a custom role with minimal privileges and grant it
-- Example:
-- CREATE ROLE service_user_role;
-- GRANT USAGE ON WAREHOUSE my_warehouse TO ROLE service_user_role;
-- GRANT ROLE service_user_role TO USER service_user;

Notice the use of PUBLIC as the default role. You want to explicitly grant roles with precise privileges rather than broad roles that open up too much. The general rule: start small and expand only when absolutely needed.

Key Pair Authentication for Service Users

Passwords are one of those things you always want to rotate and keep complex. But they can still be a weak link. Snowflake gives you the option of using RSA public/private key pairs for service users. This eliminates passwords entirely for authentication, moving to something akin to a secure handshake rather than a password entry.

Setting this up means generating your key pair outside Snowflake and then registering the public key with the user. Here’s how you do it:

-- Set RSA public key for key pair authentication instead of password
ALTER USER service_user
  SET RSA_PUBLIC_KEY = 'MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAn...';

-- To disable password login, set PASSWORD to NULL and set MUST_CHANGE_PASSWORD to FALSE
ALTER USER service_user
  SET PASSWORD = NULL
  MUST_CHANGE_PASSWORD = FALSE;

This approach is like switching from a fragile lock-and-key to a high-security badge system. It’s more complex to set up initially but pays off in reducing risk from compromised passwords. Plus, since most service users don’t interactively log in, password complexity and rotation headaches largely disappear.

Monitoring and Disabling Service Users

You don’t want service users running wild without oversight. Snowflake’s ACCESS_HISTORY and LOGIN_HISTORY views provide a window into user activity so you can spot unusual behavior or unauthorized access attempts.

Occasionally, you might want to disable a service user temporarily — maybe the service is deprecated or undergoing maintenance — without deleting the user entirely. This lets you preserve configurations and roles for when you reactivate it.

Here’s how to disable and re-enable a service user:

-- Disable the service user to prevent login without deleting the user
ALTER USER service_user SET DISABLED = TRUE;

-- To re-enable the user later
-- ALTER USER service_user SET DISABLED = FALSE;

It’s a simple switch but can be a lifesaver for operational control and audit readiness.

Practical Actions for Managing Snowflake Service Users

• Define service users up front with the principle of least privilege. Avoid broad roles like ACCOUNTADMIN unless absolutely necessary.
• Prefer key pair authentication over passwords to remove password-related risks.
• Establish and enforce password policies if passwords are still used: complexity, expiration, and lockout.
• Regularly monitor service user activity using ACCESS_HISTORY and LOGIN_HISTORY to catch anomalies early.
• Automate credential rotation externally since Snowflake doesn’t support auto-rotation internally.
• Use disable instead of drop when you want to pause service users without losing configurations.
• Document every service user’s purpose, roles, and owners to avoid orphaned accounts and privilege creep.

What Can Go Wrong When Managing Service Users

Granting overly broad roles to service users is a common misstep. Sometimes it’s done out of convenience without realizing the full blast radius of a compromised user.

Ignoring password or key rotation can leave doors open for attackers indefinitely. Snowflake doesn’t handle this for you, so it must be built into your operational discipline.

Neglecting to monitor user activity means suspicious logins or privilege escalations go unnoticed, increasing risk silently.

Dropping users without archiving or documenting their roles can break dependent pipelines and cause unexpected downtime.

“The price of greatness is responsibility.” — Winston Churchill

Service users are the silent workhorses of your Snowflake environment. Treat them as carefully as you would any critical team member and your data world will be safer, smoother, and more trustworthy. It’s not glamorous, but it’s essential. And in the end, security and reliability are the foundations we build everything else on.

Keep your users lean, your keys tight, and your eyes open. The quiet ones matter the most. 🔑🧹🔍