Does loggingServiceV2Client.ALL_SCOPES need cloud-platform scope?

[ofrobots]

I am a bit surprised by all the scopes that @google-cloud/logging requests by default:

/**
 * The scopes needed to make gRPC calls to all of the methods defined in
 * this service.
 */
var ALL_SCOPES = [
  'https://www.googleapis.com/auth/cloud-platform',
  'https://www.googleapis.com/auth/cloud-platform.read-only',
  'https://www.googleapis.com/auth/logging.admin',
  'https://www.googleapis.com/auth/logging.read',
  'https://www.googleapis.com/auth/logging.write'
];

Are these all – and specifically cloud-platform – necessary? @lukesneeringer @jmuk.

[jmuk]

These are from the service configuration yaml file in https://github.com/googleapis/googleapis/blob/master/google/logging/logging.yaml

I am not sure about the choice of the scopes, we simply make the union of the all scopes of the rules.

[ofrobots]

I am not the authority on this, but my expectation would be that the following implies that either cloud-platform or logging.admin scopes would work for the specified RPCs.

      canonical_scopes: |-
        https://www.googleapis.com/auth/logging.admin,
        https://www.googleapis.com/auth/cloud-platform

/cc @munangst: can you confirm?

[jmuk]

To be clear, cloud-platform appears on all three rules, so it needs to be eliminated from all of them if you want. Also please keep in mind that this configuration comes from our internal repository. You need to modify there.

Reviewing them, it's indeed weird to me too; for example, the second section (mostly for retrieving data) has both cloud-platform.read-only and cloud-platform. I don't know why.

[munangst]

@ofrobots Yes, you are correct, an OAuth token with any of the entries in the canonical_scopes list will be accepted. You can see this in the documentation for google.api.OAuthRequirements, which is the message used for this config.

The reason that some API methods accept multiple scopes is to allow different types of OAuth token to access that method. For instance, typically a read-only method like ListLogEntries would accept either cloud-platform.read-only or cloud-platform. A developer who wants the user to authorize access to both read-only and read-write methods would only have to request the cloud-platform scope, while a developer who only wants to authorize read-only methods would request cloud-platform.read-only. Likewise, the logging.* scopes are concentric, so logging.admin allows the admin actions as well as write and read actions.

(Note also that using scopes for access control is not recommended; Cloud IAM provides much finer-grained control over the set of operations a user or service account is allowed to perform. In most cases it's simplest to have the client request the cloud-platform or cloud-platform.read-only scope and rely on IAM roles to limit what the user can do. However, if you're writing an application for other users, you might want to request a narrower scope or set of scopes, to increase their confidence that the application isn't misusing the privileges the user granted to it.)

[ofrobots]

Yes, this would be the library for logging, rather than end user applications – so we should be requesting minimal scopes to avoid misuse of privileges.

@jmuk, @lukesneeringer converting this to a bug. Does it belong in the google-gax repo?

[jmuk]

Here's the part of the codegen to choose the list of the default scopes (https://github.com/googleapis/toolkit/blob/master/src/main/java/com/google/api/codegen/config/ServiceConfig.java#L48):

Scopes form a union and the union is used for down-scoping, so adding more scopes that
are subsets of the others already in the union essentially has no effect.
We are doing this for implementation simplicity so we don't have to compute which scopes
are subsets of the others.

So that's actually an intended behavior for "implementation simplicity" (also this is a common part of the codegen, any languages are affected). However, I don't think this causes problems so far. I mean, I agree that it's better to minimize the coverage of the scopes, but so far I'm not sure how this can be misused.

I'll open an internal discussion to gather more insights.

[stephenplusplus]

@jmuk @lukesneeringer @ofrobots what should we do here?

[evaogbe]

@jmuk What was the conclusion from the internal discussion?