Introduction

In Google Cloud Memorystore, the answer depends on which Redis product you are using. For classic Memorystore for Redis, you do not set your own requirepass value; instead, you enable Redis AUTH and Google generates the AUTH string for the instance. For Memorystore for Redis Cluster, the supported authentication model is IAM-based rather than a manually chosen shared password.

Memorystore for Redis Does Not Use a Custom requirepass

This is the main point that trips people up. On a self-managed Redis server, you might edit redis.conf and set requirepass yourself. Memorystore is a managed service, so that configuration model does not apply in the same way.

What you can do is enable Redis AUTH. Once AUTH is enabled:

• the instance requires authentication before normal Redis commands succeed
• Google generates the AUTH string for the instance
• clients must present that AUTH string when connecting

That means the practical equivalent of "add a password" is "enable AUTH," not "choose a custom password value."

Enable AUTH on a Standard Memorystore for Redis Instance

You can enable AUTH when creating the instance:

1gcloud redis instances create my-cache \
2  --region=us-central1 \
3  --size=1 \
4  --redis-version=redis_7_0 \
5  --enable-auth

You can also enable it later on an existing instance:

gcloud redis instances update my-cache \
  --region=us-central1 \
  --enable-auth

After AUTH is enabled, retrieve the generated AUTH string and configure clients to use it.

gcloud redis instances get-auth-string my-cache \
  --region=us-central1

Then connect with a Redis client:

redis-cli -h REDIS_HOST -p REDIS_PORT -a AUTH_STRING

That is the standard Memorystore for Redis workflow.

You Still Need to Protect the Connection Path

AUTH helps with access control, but it is not the whole security story. Authentication decides whether the client is allowed in. It does not automatically solve transport security for every network path by itself.

Operationally, you should still:

• restrict who can reach the VPC network
• store the AUTH string outside source control
• distribute credentials through a secure mechanism such as Secret Manager

If you enable AUTH but then hard-code the secret in the app repository, the security story is still weak.

Rotating the AUTH String

Because the AUTH string is managed by the service, rotation is not the same as changing a line in a Redis config file. In Memorystore for Redis, the AUTH string is generated by Google, and toggling AUTH off and back on can produce a new string.

That means rotation planning matters:

• retrieve the new AUTH string
• update all clients
• coordinate rollout carefully

Managed authentication is convenient, but client rollout still needs discipline.

Memorystore for Redis Cluster Uses IAM Authentication

Memorystore for Redis Cluster is different. The recommended authentication model there is IAM-based authentication, not a manually selected password. Clients authenticate with an IAM access token through the Redis AUTH command.

At a high level, the cluster flow is:

• grant the caller the right IAM role, commonly roles/redis.dbConnectionUser
• obtain an IAM access token
• use that token when connecting

Example with redis-cli:

redis-cli -h CLUSTER_HOST -p PORT -a ACCESS_TOKEN -c

So if you are using Redis Cluster, the right question is not "where do I set the password?" The right question is "how do I configure IAM authentication and token delivery for clients?"

Choose the Right Mental Model

A lot of confusion comes from mixing product models:

• self-managed Redis: direct config-file control, including requirepass
• Memorystore for Redis: managed Redis AUTH with a generated AUTH string
• Memorystore for Redis Cluster: IAM authentication with access tokens

If you apply the self-managed Redis mental model to Memorystore, you will keep looking for a password field that is not meant to exist.

The right client code should reflect the service you actually run. Standard Redis instances need the generated AUTH string. Redis Cluster clients need a valid IAM token and the permissions to connect.

Common Pitfalls

One common mistake is searching for requirepass and expecting Memorystore to let you pick an arbitrary password like a self-hosted Redis server. Standard Memorystore for Redis does not work that way.

Another pitfall is enabling AUTH and forgetting to update all clients with the generated AUTH string. The server becomes protected, but clients keep trying to connect without credentials.

A third issue is mixing guidance for Memorystore for Redis and Memorystore for Redis Cluster. The first uses generated AUTH strings, while the second uses IAM authentication.

Finally, do not treat authentication as a substitute for network security. Restrict access to the network path and handle secrets or tokens carefully.

Summary

• In standard Memorystore for Redis, you do not set a custom Redis password with requirepass; you enable AUTH and use the generated AUTH string.
• You can enable AUTH during instance creation or by updating an existing instance.
• Retrieve the generated credential with the appropriate gcloud command and pass it to Redis clients.
• In Memorystore for Redis Cluster, authentication is IAM-based rather than a manually chosen password.
• Use the authentication model that matches the specific Memorystore product you are running.