INVALID_ARGUMENT about <type>:<value>

[project-6b87f]

I'm looking to migrate to Artifact Registry, but when I run a command

gcloud projects add-iam-policy-binding my-first-project-6b87f --member='serviceAccount:service-434105066879@gcp-sa-artifactregistry.iam.gserviceaccount.com' --role='roles/storage.objectViewer'

 I get

ERROR: Policy modification failed. For a binding with condition, run "gcloud alpha iam policies lint-condition" to identify issues in condition.
ERROR: (gcloud.projects.add-iam-policy-binding) INVALID_ARGUMENT: Policy members must be of the form "<type>:<value>".
- '@type': type.googleapis.com/google.rpc.BadRequest
  fieldViolations:
  - description: Policy members must be prefixed of the form '<type>:<value>', where
      <type> is 'domain', 'group', 'serviceAccount', or 'user'.
    field: policy.bindings.member
- '@type': type.googleapis.com/google.rpc.ErrorInfo
  domain: cloudresourcemanager.googleapis.com
  reason: PROJECT_SET_IAM_DISALLOWED_MEMBER_TYPE
- '@type': type.googleapis.com/google.rpc.ResourceInfo
  resourceName: projects/my-first-project-6b87f

What's wrong? The type is serviceAccount.

[ruthseki]

Hi @project-6b87f,

Welcome to Google Cloud Community!

The error message "Policy members must be of the form <type>:<value>" indicates that the member string you're providing isn't being recognized in the correct format for the gcloud command to properly add the IAM policy binding. The problem is not with the serviceAccount type itself but that the service account's email address might be too long.

On the other hand, the error PROJECT_SET_IAM_DISALLOWED_MEMBER_TYPE strongly suggests that service accounts automatically created for Artifact Registry might not be directly added to the project-level IAM policy using this method. These service accounts are often intended for Artifact Registry's internal use and permissions are managed differently.

While you want to grant the Artifact Registry service account roles/storage.objectViewer, directly assigning it at the project level might not be the correct approach. Artifact Registry often manages permissions through its own resources, like repositories.

With that being said, you may try granting the roles/artifactregistry.reader role (or roles/artifactregistry.writer if write access is needed) to the service account on the specific Artifact Registry repository.

The roles/storage.objectViewer role is more general storage access. Using roles/artifactregistry.reader (or writer) is more specific and provides the necessary permissions to interact with Artifact Registry in the intended way. Artifact Registry uses Cloud Storage in the backend, but granting storage.objectViewer directly bypasses Artifact Registry's access control mechanisms.

By setting permissions at the repository level, you can control access to individual repositories within your Artifact Registry, providing more fine-grained control.

In general, avoid directly modifying IAM policies for Google-managed service accounts (like the one you're using) at the project level. Instead, rely on the service-specific IAM bindings for the resource itself.

By using the gcloud artifacts repositories add-iam-policy-binding command and granting the appropriate Artifact Registry-specific role, you may correctly configure access for the service account. Remember to replace the placeholders with your actual repository name, location, project ID, and service account email.

Was this helpful? If so, please accept this answer as “Solution”. If you need additional assistance, reply here within 2 business days and I’ll be happy to help.