Access Control

Cloud Machine Learning Engine uses Identity and Access Management (IAM) to manage access to resources. To grant access to a resource, assign one or more roles to a user, group, or service account.

There are three types of IAM roles that can be used in Cloud ML Engine:

  • Primitive roles (Owner, Viewer, and Editor) are common to all GCP services.

  • Predefined Cloud ML Engine roles give you fine-grained access control to your Cloud ML Engine resources at the project and model levels.

  • Custom roles enable you to choose a specific set of permissions, create your own role with those permissions, and grant the role to users in your organization.

This guide focuses on predefined Cloud ML Engine roles, their typical usage, and associated permissions.

Primitive roles

The legacy Cloud ML Engine IAM roles are based on the primitive roles that are common to all GCP services: Owner, Viewer, and Editor.

The legacy project Editor role is equivalent to the Cloud ML Engine Admin role.

The legacy project Viewer role grants the same permissions as the Cloud ML Engine Viewer role, plus access to send online prediction requests. The advantage to using the Cloud ML Engine Viewer role is that the user gets read-only access to Cloud ML Engine resources.

Predefined roles

Predefined roles grant a set of related permissions. Cloud ML Engine offers predefined roles for your project, and also for individual models, jobs, and operations.

To view a full list of permissions for each role, click on the name of the role.

Project roles

The Cloud ML Engine Admin, Developer, and Viewer roles grant varying levels of access to resources at the project level.

To add, update, or remove these roles in your Cloud ML Engine project, see the documentation on granting, changing, and revoking access to team members.

Role Title Role Name Capabilities
Cloud ML Engine Admin

roles/ml.admin

Full control of Cloud ML Engine project, and its jobs, operations, models, and versions.

Note: The primitive project Editor role is equivalent to roles/ml.admin.

Cloud ML Engine Developer

roles/ml.developer

Create training and prediction jobs, models and versions, and send online prediction requests.

Cloud ML Engine Viewer

roles/ml.viewer

Read-only access to Cloud ML Engine resources.

Model roles

The Cloud ML Engine Model Owner and Model User roles grant varying permissions to a particular model resource.

You can share models with individuals or services by granting them the Model User role.

Role Title Role Name Capabilities
Cloud ML Engine Model Owner

roles/ml.modelOwner

Full access to the model and its versions. This role is automatically granted to the user who creates the model.

Cloud ML Engine Model User

roles/ml.modelUser

Permissions to read the model and its versions, and use them for prediction. Granting this role makes it easy to share specific models.

Job and operation roles

Similar to the Model Owner role, there are owner roles at the job and operation resource levels that are assigned automatically to the user who creates the job or operation. These roles allow the user full control of any job or operation they create. For more information, see the permissions for job and operation roles.

Sharing models

This example demonstrates how to edit a policy for a particular model by adding an individual as a Model User. You can either edit the policy file directly, or quickly add and remove users using gcloud commands.

gcloud

Modifying a model policy by editing the policy file directly

You can use either JSON or YAML files with the gcloud commands. This example uses JSON.

  1. Get the policy that you want to modify, and write it to a JSON file.

    gcloud ml-engine models get-iam-policy <MODEL_NAME> --format json > iam.json
    
  2. Open the policy file (iam.json in this example), or run cat iam.json to see the policy. In the following example policy, the service account is assigned the Cloud ML Engine Model Owner role so that it has access to online prediction.

     {
        "bindings": [
        {
            "role": "roles/ml.modelOwner",
            "members": [
                "serviceAccount:my-other-app@appspot.gserviceaccount.com",
                "user:email1@gmail.com"
            ]
        }
        ],
        "etag": "BwVUJYGz8M4=",
     }
    
  3. Using a text editor, update your iam.json file as follows. Add a new object to the bindings array that defines the group members and the role for those members. For example, to grant the role roles/ml.modelUser to the user email2@gmail.com, change the example shown above as follows:

     {
        "bindings": [
        {
            "role": "roles/ml.modelOwner",
            "members": [
                "serviceAccount:my-other-app@appspot.gserviceaccount.com",
                "user:email1@gmail.com"
            ]
        },
        {
            "role": "roles/ml.modelUser",
            "members": [
                "user:email2@gmail.com"
            ]
        }
        ],
        "etag": "BwVUJYGz8M4=",
     }
    
  4. Update the project's policy by running the following command:

    gcloud ml-engine models set-iam-policy <MODEL_NAME> iam.json
    
  5. The command outputs the updated policy in YAML:

    bindings:
    - members:
      - user:email1@gmail.com
      - serviceAccount:otherapp@appspot.gserviceaccount.com
      role: roles/ml.modelOwner
    - members:
      - user:email2@gmail.com
      role: roles/ml.modelUser
    etag: BwVUJYGz8M4=
    

Modifying a policy with policy binding commands

Use the add-iam-policy-binding and remove-iam-policy-binding commands to grant, revoke, and update access to models.

Share a model with a user

  1. Use the add-iam-policy-binding command to add a user to an existing Cloud ML Engine model policy as follows:

    gcloud ml-engine models add-iam-policy-binding <MODEL_NAME> \
        --member user:email3@gmail.com --role roles/ml.modelUser
    

    The command outputs the updated policy:

        bindings:
        - members:
          - user:email1@gmail.com
          - serviceAccount:otherapp@appspot.gserviceaccount.com
          role: roles/ml.modelOwner
        - members:
          - user:email2@gmail.com
          - user:email3@gmail.com
          role: roles/ml.modelUser
        etag: BwVUJYGz8M4=
    

Share a model with a service

  1. Use the add-iam-policy-binding command to add a service account to an existing Cloud ML Engine model policy as follows:

    gcloud ml-engine models add-iam-policy-binding <MODEL_NAME> \
        --member=serviceAccount:newserviceapp@appspot.gserviceaccount.com \
        --role=roles/ml.modelOwner
    

    The command outputs the updated policy:

      bindings:
      - members:
        - user:email1@gmail.com
        - serviceAccount:otherapp@appspot.gserviceaccount.com
        - serviceAccount:newserviceapp@appspot.gserviceaccount.com
        role: roles/ml.modelOwner
      - members:
        - user:email2@gmail.com
        - user:email3@gmail.com
        role: roles/ml.modelUser
      etag: BwVUJYGz8M4=
    

Stop sharing a model

  1. To stop sharing a model with a user or service, use the remove-iam-policy-binding command to remove the user or service from an existing Cloud ML Engine model policy. In this example, we remove the Model Owner email1@gmail.com from the model policy.

    gcloud ml-engine models remove-iam-policy-binding <MODEL_NAME> \
          --member=user:email1@gmail.com \
          --role=roles/ml.modelOwner
    

    The command outputs the updated policy:

      bindings:
      - members:
        - serviceAccount:otherapp@appspot.gserviceaccount.com
        - serviceAccount:newserviceapp@appspot.gserviceaccount.com
        role: roles/ml.modelOwner
      - members:
        - user:email2@gmail.com
        - user:email3@gmail.com
        role: roles/ml.modelUser
      etag: BwVUJYGz8M4=
    

API

Modifying policy via JSON API

  1. Get the existing policy by sending the following request:

    GET https://ml.googleapis.com/v1/projects/<project>/models/<model>:getIamPolicy
    

    The command returns the current policy in the response:

       {
          "bindings": [
          {
              "role": "roles/ml.modelOwner",
              "members": [
                  "serviceAccount:my-other-app@appspot.gserviceaccount.com",
                  "user:email1@gmail.com"
              ]
          }
          ]
       }
    
  2. Once you have modified the policy, update it by sending the following request:

    POST https://ml.googleapis.com/v1/projects/<project>/models/<model>:setIamPolicy
    

    The command returns the updated policy in the response. In this example, we have added the user email2@gmail.com as a Model User:

        {
           "policy": {
               "bindings": [
               {
                   "role": "roles/ml.modelOwner",
                   "members": [
                       "serviceAccount:my-other-app@appspot.gserviceaccount.com",
                       "user:email1@gmail.com"
                   ]
               },
               {
                   "role": "roles/ml.modelUser",
                   "members": [
                       "user:email2@gmail.com"
                   ]
               }
               ]
           }
        }
    
  1. To get an access token:

    gcloud auth print-access-token
    
  2. When calling the API, pass the token value as a bearer token in an Authorization header:

    curl -s -H 'Authorization: Bearer <ACCESS_TOKEN>' \
        https://ml.googleapis.com/v1/projects/<project>/models/<model>:getIamPolicy
    

Permissions and roles

Refer to this section for a full list of permissions that are granted with each Cloud ML Engine predefined role. If these predefined roles do not meet your needs, use this section as a reference for creating your own custom roles.

Admin role

Role Name Description Permissions
roles/ml.admin Cloud ML Engine Admin

Full access to your Cloud ML Engine project, and its jobs, operations, models, and versions.

Note: Migrating to this role from the primitive project Editor role is fairly simple. If you previously used the primitive Editor role assigned at the project level, you can use this roles/ml.admin role to grant exactly the same set of permissions to the user.

  • resourcemanager.projects.get
  • ml.projects.getConfig
  • ml.jobs.create
  • ml.jobs.list
  • ml.jobs.get
  • ml.jobs.getIamPolicy
  • ml.jobs.setIamPolicy
  • ml.jobs.cancel
  • ml.operations.list
  • ml.operations.get
  • ml.operations.getIamPolicy
  • ml.operations.setIamPolicy
  • ml.operations.cancel
  • ml.models.create
  • ml.models.list
  • ml.models.get
  • ml.models.setIamPolicy
  • ml.models.getIamPolicy
  • ml.models.predict
  • ml.models.delete
  • ml.models.update
  • ml.versions.create
  • ml.versions.list
  • ml.versions.get
  • ml.versions.predict
  • ml.versions.delete

Developer role

Role Name Description Permissions
roles/ml.developer

Access to create training and prediction jobs, models and versions, and send online prediction requests.

Note: A developer receives ml.jobs.cancel and ml.jobs.update permissions on all jobs they create, because creating a job automatically grants them the Cloud ML Engine Job Owner role.

Recommendation: Grant the developer read-only access to the Cloud ML Engine logs for troubleshooting purposes.

  • resourcemanager.projects.get
  • ml.projects.getConfig
  • ml.jobs.create
  • ml.jobs.list
  • ml.jobs.get
  • ml.jobs.getIamPolicy
  • ml.operations.list
  • ml.operations.get
  • ml.operations.getIamPolicy
  • ml.models.create
  • ml.models.list
  • ml.models.get
  • ml.models.getIamPolicy
  • ml.models.predict
  • ml.versions.list
  • ml.versions.get
  • ml.versions.predict

Viewer role

Role Name Description Permissions
roles/ml.viewer

Read-only access to Cloud ML Engine resources on a particular project.

Note: The legacy project Viewer role grants a user the same permissions as the roles/ml.viewer role, plus access to send online prediction requests.

  • resourcemanager.projects.get
  • ml.projects.getConfig
  • ml.jobs.list
  • ml.jobs.get
  • ml.operations.list
  • ml.operations.get
  • ml.models.list
  • ml.models.get
  • ml.versions.list
  • ml.versions.get

Model Owner role

Role Name Description Permissions
roles/ml.modelOwner Full access to the model and its versions. This role is automatically granted to the user who creates the model.
  • ml.models.get
  • ml.models.setIamPolicy
  • ml.models.getIamPolicy
  • ml.models.predict
  • ml.models.delete
  • ml.models.update
  • ml.versions.create
  • ml.versions.list
  • ml.versions.get
  • ml.versions.predict
  • ml.versions.delete

Model User role

Role Name Description Permissions
roles/ml.modelUser Permissions to read the model and its versions, and to use them for prediction.
  • ml.models.get
  • ml.models.predict
  • ml.versions.list
  • ml.versions.get
  • ml.versions.predict

Job Owner role

Role Name Description Permissions
roles/ml.jobOwner

Full access to all permissions for a particular job resource. The Job Owner role is granted automatically to the user who creates that job.

For example, a user who has the Cloud ML Engine Developer role on a project can create jobs, list all jobs, and get all jobs in a given project. The Developer has access to cancel only the job(s) they have created.

  • ml.jobs.get
  • ml.jobs.getIamPolicy
  • ml.jobs.cancel

Operation Owner role

Role Name Description Permissions
roles/ml.operationOwner

Full access to all permissions for a particular operation resource. The Operation Owner role is granted to the user automatically on any operations that the user indirectly creates when creating a version or a model, so that the user always can get and cancel their own operations.

  • ml.operations.get
  • ml.operations.getIamPolicy
  • ml.operations.cancel

Permissions needed for training and prediction

For convenience, this table summarizes the permissions that are specifically required for training and prediction:

Task Required Permission(s)
Training
  • ml.jobs.create
Batch prediction
  • ml.jobs.create
  • ml.models.predict*
  • ml.versions.predict*

Note: You can create a batch prediction job without a deployed version by specifying the location of a model saved in Google Cloud Storage. This type of batch prediction job requires only the ml.jobs.create permission.

To create a batch prediction job that uses a deployed version, you will also need either ml.models.predict or ml.versions.predict, but not both.

Online prediction
  • ml.models.predict
  • ml.versions.predict

Permissions required for methods

For convenience, this section lists the permissions required to call each method in Cloud ML Engine:

Method Required Permission(s)
projects.getConfig ml.projects.getConfig
projects.jobs.cancel ml.jobs.cancel
projects.jobs.create ml.jobs.create

Note: To create a batch prediction job that uses a deployed version, you will also need either ml.models.predict or ml.versions.predict, but not both.

projects.jobs.get ml.jobs.get
projects.jobs.list ml.jobs.list
projects.models.create ml.models.create
projects.models.delete ml.models.delete
projects.models.get ml.models.get
projects.models.list ml.models.list
projects.models.versions.create ml.versions.create
projects.models.versions.delete ml.versions.delete
projects.models.versions.get ml.versions.get
projects.models.versions.list ml.versions.list
projects.models.versions.setDefault ml.models.update
projects.operations.cancel ml.operations.cancel
projects.operations.delete ml.operations.delete
projects.operations.get ml.operations.get
projects.operations.list ml.operations.list

What's next

Monitor your resources on the go

Get the Google Cloud Console app to help you manage your projects.

Send feedback about...

Cloud Machine Learning Engine (Cloud ML Engine)