How to add a role binding to a specific memorystore instance?

Question

I want to add a role (Cloud Memorystore Redis Editor) binding to a specific redis or memcached instance in the memorystore.

I usually do this with the binding wizard on the info page of an instance. It is not shown at all at memorystore instance pages.

Is there a way to do this other than adding a member with conditions on the IAM page?

Also, when I try to list grantable roles for an instance with gcloud iam list-grantable-roles <resource_name> it returns empty for the memcached instance, and gives invalid argument name error for the redis instance.

Thanks

---

Edit:

I want to add a member with a specific role to a redis resource. The role I want to add is Cloud Memorystore Redis Editor

I added screenshot with an example from Bigtable instance. I don't see the panel from the second screenshot in the redis instance. There is no option to open that panel.

---

Selecting an instances shows "Add Member" button under "permissions" tab

---

This panel allows me to select a member and give roles grantable to this resource

Answer 1

I don't think permissions on a per-instance basis are possible for Redis. I got this quote from Google's Access control and permissions page for Memorystore for Redis (source).

Note: To call a method, you must also have the required scopes as described in the method's reference page, in addition to the permissions below. For more information, see Authorizing requests with OAuth 2.0. All permissions are applied to the project. You cannot apply different permissions based on the instance or other lower-level object.

If you do need the instances to be isolated in terms of access management, I have some suggestions:

1. Place the Redis instances in separate projects if they have completely different purposes.
2. If feasible, you could separate reader and writer permissions under different service accounts.
3. Do not grant roles/owner permissions, instead use roles/redis.editor, roles/redis.viewer and roles/redis.admin.

Bullet number three might seem obvious, but I have seen many people (even on Stackoverflow) suggesting that someone should put owner permissions on a service account to get something to work. And indeed it does work, but it is very bad practice from a security standpoint.