feat(cloudasset): update the api

#### cloudasset:v1

The following keys were added:
- schemas.GoogleCloudAssetV1AnalyzeOrgPolicyGovernedAssetsResponseGovernedIamPolicy.properties.assetType.type (Total Keys: 1)
- schemas.GoogleCloudAssetV1AnalyzeOrgPolicyGovernedAssetsResponseGovernedResource.properties.assetType.type (Total Keys: 1)
- schemas.GoogleCloudAssetV1GovernedContainer.properties.folders (Total Keys: 2)
- schemas.GoogleCloudAssetV1GovernedContainer.properties.organization.type (Total Keys: 1)
- schemas.GoogleCloudAssetV1GovernedContainer.properties.project.type (Total Keys: 1)
- schemas.GoogleCloudAssetV1Rule.properties.conditionEvaluation.$ref (Total Keys: 1)
- schemas.OrgPolicyResult.properties.folders (Total Keys: 2)
- schemas.OrgPolicyResult.properties.organization.type (Total Keys: 1)
- schemas.OrgPolicyResult.properties.project.type (Total Keys: 1)

docs/dyn/cloudasset_v1.assets.html

@@ -461,7 +461,7 @@ <h3>Method Details</h3>
           &quot;egressPolicies&quot;: [ # List of EgressPolicies to apply to the perimeter. A perimeter may have multiple EgressPolicies, each of which is evaluated separately. Access is granted if any EgressPolicy grants it. Must be empty for a perimeter bridge.
             { # Policy for egress from perimeter. EgressPolicies match requests based on `egress_from` and `egress_to` stanzas. For an EgressPolicy to match, both `egress_from` and `egress_to` stanzas must be matched. If an EgressPolicy matches a request, the request is allowed to span the ServicePerimeter boundary. For example, an EgressPolicy can be used to allow VMs on networks within the ServicePerimeter to access a defined set of projects outside the perimeter in certain contexts (e.g. to read data from a Cloud Storage bucket or query against a BigQuery dataset). EgressPolicies are concerned with the *resources* that a request relates as well as the API services and API actions being used. They do not related to the direction of data movement. More detailed documentation for this concept can be found in the descriptions of EgressFrom and EgressTo.
               &quot;egressFrom&quot;: { # Defines the conditions under which an EgressPolicy matches a request. Conditions based on information about the source of the request. Note that if the destination of the request is also protected by a ServicePerimeter, then that ServicePerimeter must have an IngressPolicy which allows access in order for this request to succeed. # Defines conditions on the source of a request causing this EgressPolicy to apply.
-                &quot;identities&quot;: [ # A list of identities that are allowed access through this [EgressPolicy]. Should be in the format of email address. The email address should represent individual user or service account only.
+                &quot;identities&quot;: [ # A list of identities that are allowed access through this [EgressPolicy], in the format of `user:{email_id}` or `serviceAccount:{email_id}`.
                   &quot;A String&quot;,
                 ],
                 &quot;identityType&quot;: &quot;A String&quot;, # Specifies the type of identities that are allowed access to outside the perimeter. If left unspecified, then members of `identities` field will be allowed access.
@@ -496,7 +496,7 @@ <h3>Method Details</h3>
           &quot;ingressPolicies&quot;: [ # List of IngressPolicies to apply to the perimeter. A perimeter may have multiple IngressPolicies, each of which is evaluated separately. Access is granted if any Ingress Policy grants it. Must be empty for a perimeter bridge.
             { # Policy for ingress into ServicePerimeter. IngressPolicies match requests based on `ingress_from` and `ingress_to` stanzas. For an ingress policy to match, both the `ingress_from` and `ingress_to` stanzas must be matched. If an IngressPolicy matches a request, the request is allowed through the perimeter boundary from outside the perimeter. For example, access from the internet can be allowed either based on an AccessLevel or, for traffic hosted on Google Cloud, the project of the source network. For access from private networks, using the project of the hosting network is required. Individual ingress policies can be limited by restricting which services and/or actions they match using the `ingress_to` field.
               &quot;ingressFrom&quot;: { # Defines the conditions under which an IngressPolicy matches a request. Conditions are based on information about the source of the request. The request must satisfy what is defined in `sources` AND identity related fields in order to match. # Defines the conditions on the source of a request causing this IngressPolicy to apply.
-                &quot;identities&quot;: [ # A list of identities that are allowed access through this ingress policy. Should be in the format of email address. The email address should represent individual user or service account only.
+                &quot;identities&quot;: [ # A list of identities that are allowed access through this ingress policy, in the format of `user:{email_id}` or `serviceAccount:{email_id}`.
                   &quot;A String&quot;,
                 ],
                 &quot;identityType&quot;: &quot;A String&quot;, # Specifies the type of identities that are allowed access from outside the perimeter. If left unspecified, then members of `identities` field will be allowed access.
@@ -545,7 +545,7 @@ <h3>Method Details</h3>
           &quot;egressPolicies&quot;: [ # List of EgressPolicies to apply to the perimeter. A perimeter may have multiple EgressPolicies, each of which is evaluated separately. Access is granted if any EgressPolicy grants it. Must be empty for a perimeter bridge.
             { # Policy for egress from perimeter. EgressPolicies match requests based on `egress_from` and `egress_to` stanzas. For an EgressPolicy to match, both `egress_from` and `egress_to` stanzas must be matched. If an EgressPolicy matches a request, the request is allowed to span the ServicePerimeter boundary. For example, an EgressPolicy can be used to allow VMs on networks within the ServicePerimeter to access a defined set of projects outside the perimeter in certain contexts (e.g. to read data from a Cloud Storage bucket or query against a BigQuery dataset). EgressPolicies are concerned with the *resources* that a request relates as well as the API services and API actions being used. They do not related to the direction of data movement. More detailed documentation for this concept can be found in the descriptions of EgressFrom and EgressTo.
               &quot;egressFrom&quot;: { # Defines the conditions under which an EgressPolicy matches a request. Conditions based on information about the source of the request. Note that if the destination of the request is also protected by a ServicePerimeter, then that ServicePerimeter must have an IngressPolicy which allows access in order for this request to succeed. # Defines conditions on the source of a request causing this EgressPolicy to apply.
-                &quot;identities&quot;: [ # A list of identities that are allowed access through this [EgressPolicy]. Should be in the format of email address. The email address should represent individual user or service account only.
+                &quot;identities&quot;: [ # A list of identities that are allowed access through this [EgressPolicy], in the format of `user:{email_id}` or `serviceAccount:{email_id}`.
                   &quot;A String&quot;,
                 ],
                 &quot;identityType&quot;: &quot;A String&quot;, # Specifies the type of identities that are allowed access to outside the perimeter. If left unspecified, then members of `identities` field will be allowed access.
@@ -580,7 +580,7 @@ <h3>Method Details</h3>
           &quot;ingressPolicies&quot;: [ # List of IngressPolicies to apply to the perimeter. A perimeter may have multiple IngressPolicies, each of which is evaluated separately. Access is granted if any Ingress Policy grants it. Must be empty for a perimeter bridge.
             { # Policy for ingress into ServicePerimeter. IngressPolicies match requests based on `ingress_from` and `ingress_to` stanzas. For an ingress policy to match, both the `ingress_from` and `ingress_to` stanzas must be matched. If an IngressPolicy matches a request, the request is allowed through the perimeter boundary from outside the perimeter. For example, access from the internet can be allowed either based on an AccessLevel or, for traffic hosted on Google Cloud, the project of the source network. For access from private networks, using the project of the hosting network is required. Individual ingress policies can be limited by restricting which services and/or actions they match using the `ingress_to` field.
               &quot;ingressFrom&quot;: { # Defines the conditions under which an IngressPolicy matches a request. Conditions are based on information about the source of the request. The request must satisfy what is defined in `sources` AND identity related fields in order to match. # Defines the conditions on the source of a request causing this IngressPolicy to apply.
-                &quot;identities&quot;: [ # A list of identities that are allowed access through this ingress policy. Should be in the format of email address. The email address should represent individual user or service account only.
+                &quot;identities&quot;: [ # A list of identities that are allowed access through this ingress policy, in the format of `user:{email_id}` or `serviceAccount:{email_id}`.
                   &quot;A String&quot;,
                 ],
                 &quot;identityType&quot;: &quot;A String&quot;, # Specifies the type of identities that are allowed access from outside the perimeter. If left unspecified, then members of `identities` field will be allowed access.