google_api_iam v0.4.0 API Reference

Modules

API calls for all endpoints tagged IamPolicies.

API calls for all endpoints tagged Organizations.

API calls for all endpoints tagged Permissions.

API calls for all endpoints tagged Projects.

API calls for all endpoints tagged Roles.

Handle Tesla connections for GoogleApi.IAM.V1.

Helper functions for deserializing responses into models.

Specifies the audit configuration for a service. The configuration determines which permission types are logged, and what identities, if any, are exempted from logging. An AuditConfig must have one or more AuditLogConfigs. If there are AuditConfigs for both `allServices` and a specific service, the union of the two AuditConfigs is used for that service: the log_types specified in each AuditConfig are enabled, and the exempted_members in each AuditLogConfig are exempted. Example Policy with multiple AuditConfigs: { "audit_configs": [ { "service": "allServices" "audit_log_configs": [ { "log_type": "DATA_READ", "exempted_members": [ "user:foo@gmail.com" ] }, { "log_type": "DATA_WRITE", }, { "log_type": "ADMIN_READ", } ] }, { "service": "fooservice.googleapis.com" "audit_log_configs": [ { "log_type": "DATA_READ", }, { "log_type": "DATA_WRITE", "exempted_members": [ "user:bar@gmail.com" ] } ] } ] } For fooservice, this policy enables DATA_READ, DATA_WRITE and ADMIN_READ logging. It also exempts foo@gmail.com from DATA_READ logging, and bar@gmail.com from DATA_WRITE logging.

Audit log information specific to Cloud IAM. This message is serialized as an `Any` type in the `ServiceData` message of an `AuditLog` message.

Provides the configuration for logging a type of permissions. Example: { "audit_log_configs": [ { "log_type": "DATA_READ", "exempted_members": [ "user:foo@gmail.com" ] }, { "log_type": "DATA_WRITE", } ] } This enables 'DATA_READ' and 'DATA_WRITE' logging, while exempting foo@gmail.com from DATA_READ logging.

Contains information about an auditable service.

Associates `members` with a `role`.

One delta entry for Binding. Each individual change (only one member in each entry) to a binding will be a separate entry.

The request to create a new role.

The service account key create request.

The service account create request.

The service account disable request.

A generic empty message that you can re-use to avoid defining duplicated empty messages in your APIs. A typical example is to use it as the request or the response type of an API method. For instance: service Foo { rpc Bar(google.protobuf.Empty) returns (google.protobuf.Empty); } The JSON representation for `Empty` is empty JSON object `{}`.

The service account enable request.

Represents an expression text. Example: title: "User account presence" description: "Determines whether the request has a user account" expression: "size(request.user) > 0"

The request to lint a Cloud IAM policy object. LintPolicy is currently functional only for `lint_object` of type `condition`.

The response of a lint operation. An empty response indicates the operation was able to fully execute and no lint issue was found.

Structured response of a single validation unit.

The response containing the roles defined under a resource.

The service account keys list response.

The service account list response.

The patch service account request.

A permission which can be included by a role.

Defines an Identity and Access Management (IAM) policy. It is used to specify access control policies for Cloud Platform resources. A `Policy` consists of a list of `bindings`. A `binding` binds a list of `members` to a `role`, where the members can be user accounts, Google groups, Google domains, and service accounts. A `role` is a named list of permissions defined by IAM. JSON Example { "bindings": [ { "role": "roles/owner", "members": [ "user:mike@example.com", "group:admins@example.com", "domain:google.com", "serviceAccount:my-other-app@appspot.gserviceaccount.com" ] }, { "role": "roles/viewer", "members": ["user:sean@example.com"] } ] } YAML Example bindings: - members: - user:mike@example.com - group:admins@example.com - domain:google.com - serviceAccount:my-other-app@appspot.gserviceaccount.com role: roles/owner - members: - user:sean@example.com role: roles/viewer For a description of IAM and its features, see the IAM developer's guide.

The difference delta between two policies.

A request to get the list of auditable services for a resource.

A response containing a list of auditable services for a resource.

The grantable role query request.

The grantable role query response.

A request to get permissions which can be tested on a resource.

The response containing permissions which can be tested on a resource.

A role in the Identity and Access Management API.

A service account in the Identity and Access Management API. To create a service account, specify the `project_id` and the `account_id` for the account. The `account_id` is unique within the project, and is used to generate the service account email address and a stable `unique_id`. If the account already exists, the account's resource name is returned in the format of projects/{PROJECT_ID}/serviceAccounts/{ACCOUNT}. The caller can use the name in other methods to access the account. All other methods can identify the service account using the format `projects/{PROJECT_ID}/serviceAccounts/{ACCOUNT}`. Using `-` as a wildcard for the `PROJECT_ID` will infer the project from the account. The `ACCOUNT` value can be the `email` address or the `unique_id` of the service account.

Represents a service account key. A service account has two sets of key-pairs: user-managed, and system-managed. User-managed key-pairs can be created and deleted by users. Users are responsible for rotating these keys periodically to ensure security of their service accounts. Users retain the private key of these key-pairs, and Google retains ONLY the public key. System-managed keys are automatically rotated by Google, and are used for signing for a maximum of two weeks. The rotation process is probabilistic, and usage of the new key will gradually ramp up and down over the key's lifetime. We recommend caching the public key set for a service account for no more than 24 hours to ensure you have access to the latest keys. Public keys for all service accounts are also published at the OAuth2 Service Account API.

Request message for `SetIamPolicy` method.

The service account sign blob request.

The service account sign blob response.

The service account sign JWT request.

The service account sign JWT response.

Request message for `TestIamPermissions` method.

Response message for `TestIamPermissions` method.

The request to undelete an existing role.

The service account undelete request.

Attributes

  • restoredAccount (ServiceAccount): Metadata for the restored service account. Defaults to: null.

Helper functions for building Tesla requests.