Учетные данные Google предоставляются двумя типами учетных записей: учетными записями служб и обычными (человеческими?) Учетными записями (например, @gmail.com, @your.email). Типы токенов, выпущенных для этих учетных записей, различаются, но оба они аутентифицируются для служб.
Когда вы используете gcloud, вы часто используете человеческие учетные записи, которые вы ранее аутентифицировали с помощью gcloud auth login и могут отображаться с gcloud auth list.
В этом случае вы также используете эти gcloud человеческие учетные данные с curl, потому что вы получаете токен доступа с помощью gcloud auth print-access-token. Два ваших примера эффективно аутентифицированы с использованием одной и той же (возможно, человеческой) учетной записи.
Если вы хотите, чтобы одна служба аутентифицировалась для другой, рекомендуется использовать учетные записи служб. В процессе нет человека, поддерживающего трехстороннюю аутентификацию OAuth, поэтому учетные записи служб используют двухстороннюю аутентификацию (см. ссылка ).
Обычно для сервисов Cloud Platform учетные данные также должны иметь роли IAM, которые описывают разрешения, которые разрешают их использование, но некоторые сервисы Cloud Platform (IIR C ML) (пока) не реализуют IAM, поэтому авторизация достигается только с использованием областей действия OAuth, и вы можете использовать vanilla учетные записи служб, для которых не назначены c привязки IAM.
ПРИМЕЧАНИЕ можно аутентифицировать gcloud с помощью службы учетные записи тоже gcloud auth activate-service-account, но IIR C этот подход не рекомендуется.