pub struct ServicePerimeter {
pub description: Option<String>,
pub name: Option<String>,
pub perimeter_type: Option<String>,
pub spec: Option<ServicePerimeterConfig>,
pub status: Option<ServicePerimeterConfig>,
pub title: Option<String>,
pub use_explicit_dry_run_spec: Option<bool>,
}
Expand description
ServicePerimeter
describes a set of Google Cloud resources which can freely import and export data amongst themselves, but not export outside of the ServicePerimeter
. If a request with a source within this ServicePerimeter
has a target outside of the ServicePerimeter
, the request will be blocked. Otherwise the request is allowed. There are two types of Service Perimeter - Regular and Bridge. Regular Service Perimeters cannot overlap, a single Google Cloud project or VPC network can only belong to a single regular Service Perimeter. Service Perimeter Bridges can contain only Google Cloud projects as members, a single Google Cloud project may belong to multiple Service Perimeter Bridges.
§Activities
This type is used in activities, which are methods you may call on this type or where this type is involved in. The list links the activity name, along with information about where it is used (one of request and response).
- service perimeters create access policies (request)
- service perimeters get access policies (response)
- service perimeters patch access policies (request)
Fields§
§description: Option<String>
Description of the ServicePerimeter
and its use. Does not affect behavior.
name: Option<String>
Resource name for the ServicePerimeter
. Format: accessPolicies/{access_policy}/servicePerimeters/{service_perimeter}
. The service_perimeter
component must begin with a letter, followed by alphanumeric characters or _
. After you create a ServicePerimeter
, you cannot change its name
.
perimeter_type: Option<String>
Perimeter type indicator. A single project or VPC network is allowed to be a member of single regular perimeter, but multiple service perimeter bridges. A project cannot be a included in a perimeter bridge without being included in regular perimeter. For perimeter bridges, the restricted service list as well as access level lists must be empty.
spec: Option<ServicePerimeterConfig>
Proposed (or dry run) ServicePerimeter configuration. This configuration allows to specify and test ServicePerimeter configuration without enforcing actual access restrictions. Only allowed to be set when the “use_explicit_dry_run_spec” flag is set.
status: Option<ServicePerimeterConfig>
Current ServicePerimeter configuration. Specifies sets of resources, restricted services and access levels that determine perimeter content and boundaries.
title: Option<String>
Human readable title. Must be unique within the Policy.
use_explicit_dry_run_spec: Option<bool>
Use explicit dry run spec flag. Ordinarily, a dry-run spec implicitly exists for all Service Perimeters, and that spec is identical to the status for those Service Perimeters. When this flag is set, it inhibits the generation of the implicit spec, thereby allowing the user to explicitly provide a configuration (“spec”) to use in a dry-run version of the Service Perimeter. This allows the user to test changes to the enforced config (“status”) without actually enforcing them. This testing is done through analyzing the differences between currently enforced and suggested restrictions. use_explicit_dry_run_spec must bet set to True if any of the fields in the spec are set to non-default values.
Trait Implementations§
source§impl Clone for ServicePerimeter
impl Clone for ServicePerimeter
source§fn clone(&self) -> ServicePerimeter
fn clone(&self) -> ServicePerimeter
1.0.0 · source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read more