ServicePerimeter

ServicePerimeter describes a set of GCP 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 GCP project can only belong to a single regular Service Perimeter. Service Perimeter Bridges can contain only GCP projects as members, a single GCP project may belong to multiple Service Perimeter Bridges.

To get more information about ServicePerimeter, see:

API documentation
How-to Guides
- Service Perimeter Quickstart

Create a ServicePerimeter Resource

new ServicePerimeter(name: string, args: ServicePerimeterArgs, opts?: CustomResourceOptions);

def ServicePerimeter(resource_name, opts=None, description=None, name=None, parent=None, perimeter_type=None, spec=None, status=None, title=None, use_explicit_dry_run_spec=None, __props__=None);

func NewServicePerimeter(ctx *Context, name string, args ServicePerimeterArgs, opts ...ResourceOption) (*ServicePerimeter, error)

public ServicePerimeter(string name, ServicePerimeterArgs args, CustomResourceOptions? opts = null)

name string: The unique name of the resource.
args ServicePerimeterArgs: The arguments to resource properties.
opts CustomResourceOptions: Bag of options to control resource's behavior.

resource_name str: The unique name of the resource.
opts ResourceOptions: A bag of options that control this resource's behavior.

ctx Context: Context object for the current deployment.
name string: The unique name of the resource.
args ServicePerimeterArgs: The arguments to resource properties.
opts ResourceOption: Bag of options to control resource's behavior.

name string: The unique name of the resource.
args ServicePerimeterArgs: The arguments to resource properties.
opts CustomResourceOptions: Bag of options to control resource's behavior.

ServicePerimeter Resource Properties

To learn more about resource properties and how to use them, see Inputs and Outputs in the Programming Model docs.

Inputs

The ServicePerimeter resource accepts the following input properties:

Parent string: The AccessPolicy this ServicePerimeter lives in. Format: accessPolicies/{policy_id}
Title string: Human readable title. Must be unique within the Policy.
Description string: Description of the ServicePerimeter and its use. Does not affect behavior.
Name string: Resource name for the ServicePerimeter. The shortname component must begin with a letter and only include alphanumeric and ‘’. Format: accessPolicies/{policy_id}/servicePerimeters/{short_name}
PerimeterType string: Specifies the type of the Perimeter. There are two types: regular and bridge. Regular Service Perimeter contains resources, access levels, and restricted services. Every resource can be in at most ONE regular Service Perimeter. In addition to being in a regular service perimeter, a resource can also be in zero or more perimeter bridges. A perimeter bridge only contains resources. Cross project operations are permitted if all effected resources share some perimeter (whether bridge or regular). Perimeter Bridge does not contain access levels or services: those are governed entirely by the regular perimeter that resource is in. Perimeter Bridges are typically useful when building more complex topologies with many independent perimeters that need to share some data with a common perimeter, but should not be able to share data among themselves.
Spec ServicePerimeterSpecArgs: 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 useExplicitDryRunSpec flag is set. Structure is documented below.
Status ServicePerimeterStatusArgs: ServicePerimeter configuration. Specifies sets of resources, restricted services and access levels that determine perimeter content and boundaries. Structure is documented below.
UseExplicitDryRunSpec 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. useExplicitDryRunSpec must bet set to True if any of the fields in the spec are set to non-default values.

Parent string: The AccessPolicy this ServicePerimeter lives in. Format: accessPolicies/{policy_id}
Title string: Human readable title. Must be unique within the Policy.
Description string: Description of the ServicePerimeter and its use. Does not affect behavior.
Name string: Resource name for the ServicePerimeter. The shortname component must begin with a letter and only include alphanumeric and ‘’. Format: accessPolicies/{policy_id}/servicePerimeters/{short_name}
PerimeterType string: Specifies the type of the Perimeter. There are two types: regular and bridge. Regular Service Perimeter contains resources, access levels, and restricted services. Every resource can be in at most ONE regular Service Perimeter. In addition to being in a regular service perimeter, a resource can also be in zero or more perimeter bridges. A perimeter bridge only contains resources. Cross project operations are permitted if all effected resources share some perimeter (whether bridge or regular). Perimeter Bridge does not contain access levels or services: those are governed entirely by the regular perimeter that resource is in. Perimeter Bridges are typically useful when building more complex topologies with many independent perimeters that need to share some data with a common perimeter, but should not be able to share data among themselves.
Spec ServicePerimeterSpec: 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 useExplicitDryRunSpec flag is set. Structure is documented below.
Status ServicePerimeterStatus: ServicePerimeter configuration. Specifies sets of resources, restricted services and access levels that determine perimeter content and boundaries. Structure is documented below.
UseExplicitDryRunSpec 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. useExplicitDryRunSpec must bet set to True if any of the fields in the spec are set to non-default values.

parent string: The AccessPolicy this ServicePerimeter lives in. Format: accessPolicies/{policy_id}
title string: Human readable title. Must be unique within the Policy.
description string: Description of the ServicePerimeter and its use. Does not affect behavior.
name string: Resource name for the ServicePerimeter. The shortname component must begin with a letter and only include alphanumeric and ‘’. Format: accessPolicies/{policy_id}/servicePerimeters/{short_name}
perimeterType string: Specifies the type of the Perimeter. There are two types: regular and bridge. Regular Service Perimeter contains resources, access levels, and restricted services. Every resource can be in at most ONE regular Service Perimeter. In addition to being in a regular service perimeter, a resource can also be in zero or more perimeter bridges. A perimeter bridge only contains resources. Cross project operations are permitted if all effected resources share some perimeter (whether bridge or regular). Perimeter Bridge does not contain access levels or services: those are governed entirely by the regular perimeter that resource is in. Perimeter Bridges are typically useful when building more complex topologies with many independent perimeters that need to share some data with a common perimeter, but should not be able to share data among themselves.
spec ServicePerimeterSpec: 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 useExplicitDryRunSpec flag is set. Structure is documented below.
status ServicePerimeterStatus: ServicePerimeter configuration. Specifies sets of resources, restricted services and access levels that determine perimeter content and boundaries. Structure is documented below.
useExplicitDryRunSpec boolean: 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. useExplicitDryRunSpec must bet set to True if any of the fields in the spec are set to non-default values.

parent str: The AccessPolicy this ServicePerimeter lives in. Format: accessPolicies/{policy_id}
title str: Human readable title. Must be unique within the Policy.
description str: Description of the ServicePerimeter and its use. Does not affect behavior.
name str: Resource name for the ServicePerimeter. The shortname component must begin with a letter and only include alphanumeric and ‘’. Format: accessPolicies/{policy_id}/servicePerimeters/{short_name}
perimeter_type str: Specifies the type of the Perimeter. There are two types: regular and bridge. Regular Service Perimeter contains resources, access levels, and restricted services. Every resource can be in at most ONE regular Service Perimeter. In addition to being in a regular service perimeter, a resource can also be in zero or more perimeter bridges. A perimeter bridge only contains resources. Cross project operations are permitted if all effected resources share some perimeter (whether bridge or regular). Perimeter Bridge does not contain access levels or services: those are governed entirely by the regular perimeter that resource is in. Perimeter Bridges are typically useful when building more complex topologies with many independent perimeters that need to share some data with a common perimeter, but should not be able to share data among themselves.
spec Dict[ServicePerimeterSpec]: 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 useExplicitDryRunSpec flag is set. Structure is documented below.
status Dict[ServicePerimeterStatus]: ServicePerimeter configuration. Specifies sets of resources, restricted services and access levels that determine perimeter content and boundaries. Structure is documented below.
use_explicit_dry_run_spec 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. useExplicitDryRunSpec must bet set to True if any of the fields in the spec are set to non-default values.

Outputs

All input properties are implicitly available as output properties. Additionally, the ServicePerimeter resource produces the following output properties:

CreateTime string: Time the AccessPolicy was created in UTC.
Id string: The provider-assigned unique ID for this managed resource.
UpdateTime string: Time the AccessPolicy was updated in UTC.

CreateTime string: Time the AccessPolicy was created in UTC.
Id string: The provider-assigned unique ID for this managed resource.
UpdateTime string: Time the AccessPolicy was updated in UTC.

createTime string: Time the AccessPolicy was created in UTC.
id string: The provider-assigned unique ID for this managed resource.
updateTime string: Time the AccessPolicy was updated in UTC.

create_time str: Time the AccessPolicy was created in UTC.
id str: The provider-assigned unique ID for this managed resource.
update_time str: Time the AccessPolicy was updated in UTC.

Look up an Existing ServicePerimeter Resource

Get an existing ServicePerimeter resource’s state with the given name, ID, and optional extra properties used to qualify the lookup.

public static get(name: string, id: Input<ID>, state?: ServicePerimeterState, opts?: CustomResourceOptions): ServicePerimeter

static get(resource_name, id, opts=None, create_time=None, description=None, name=None, parent=None, perimeter_type=None, spec=None, status=None, title=None, update_time=None, use_explicit_dry_run_spec=None, __props__=None);

func GetServicePerimeter(ctx *Context, name string, id IDInput, state *ServicePerimeterState, opts ...ResourceOption) (*ServicePerimeter, error)

public static ServicePerimeter Get(string name, Input<string> id, ServicePerimeterState? state, CustomResourceOptions? opts = null)

name: The unique name of the resulting resource.
id: The unique provider ID of the resource to lookup.
state: Any extra arguments used during the lookup.
opts: A bag of options that control this resource's behavior.

resource_name: The unique name of the resulting resource.
id: The unique provider ID of the resource to lookup.

name: The unique name of the resulting resource.
id: The unique provider ID of the resource to lookup.
state: Any extra arguments used during the lookup.
opts: A bag of options that control this resource's behavior.

name: The unique name of the resulting resource.
id: The unique provider ID of the resource to lookup.
state: Any extra arguments used during the lookup.
opts: A bag of options that control this resource's behavior.

The following state arguments are supported:

CreateTime string: Time the AccessPolicy was created in UTC.
Description string: Description of the ServicePerimeter and its use. Does not affect behavior.
Name string: Resource name for the ServicePerimeter. The shortname component must begin with a letter and only include alphanumeric and ‘’. Format: accessPolicies/{policy_id}/servicePerimeters/{short_name}
Parent string: The AccessPolicy this ServicePerimeter lives in. Format: accessPolicies/{policy_id}
PerimeterType string: Specifies the type of the Perimeter. There are two types: regular and bridge. Regular Service Perimeter contains resources, access levels, and restricted services. Every resource can be in at most ONE regular Service Perimeter. In addition to being in a regular service perimeter, a resource can also be in zero or more perimeter bridges. A perimeter bridge only contains resources. Cross project operations are permitted if all effected resources share some perimeter (whether bridge or regular). Perimeter Bridge does not contain access levels or services: those are governed entirely by the regular perimeter that resource is in. Perimeter Bridges are typically useful when building more complex topologies with many independent perimeters that need to share some data with a common perimeter, but should not be able to share data among themselves.
Spec ServicePerimeterSpecArgs: 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 useExplicitDryRunSpec flag is set. Structure is documented below.
Status ServicePerimeterStatusArgs: ServicePerimeter configuration. Specifies sets of resources, restricted services and access levels that determine perimeter content and boundaries. Structure is documented below.
Title string: Human readable title. Must be unique within the Policy.
UpdateTime string: Time the AccessPolicy was updated in UTC.
UseExplicitDryRunSpec 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. useExplicitDryRunSpec must bet set to True if any of the fields in the spec are set to non-default values.

CreateTime string: Time the AccessPolicy was created in UTC.
Description string: Description of the ServicePerimeter and its use. Does not affect behavior.
Name string: Resource name for the ServicePerimeter. The shortname component must begin with a letter and only include alphanumeric and ‘’. Format: accessPolicies/{policy_id}/servicePerimeters/{short_name}
Parent string: The AccessPolicy this ServicePerimeter lives in. Format: accessPolicies/{policy_id}
PerimeterType string: Specifies the type of the Perimeter. There are two types: regular and bridge. Regular Service Perimeter contains resources, access levels, and restricted services. Every resource can be in at most ONE regular Service Perimeter. In addition to being in a regular service perimeter, a resource can also be in zero or more perimeter bridges. A perimeter bridge only contains resources. Cross project operations are permitted if all effected resources share some perimeter (whether bridge or regular). Perimeter Bridge does not contain access levels or services: those are governed entirely by the regular perimeter that resource is in. Perimeter Bridges are typically useful when building more complex topologies with many independent perimeters that need to share some data with a common perimeter, but should not be able to share data among themselves.
Spec ServicePerimeterSpec: 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 useExplicitDryRunSpec flag is set. Structure is documented below.
Status ServicePerimeterStatus: ServicePerimeter configuration. Specifies sets of resources, restricted services and access levels that determine perimeter content and boundaries. Structure is documented below.
Title string: Human readable title. Must be unique within the Policy.
UpdateTime string: Time the AccessPolicy was updated in UTC.
UseExplicitDryRunSpec 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. useExplicitDryRunSpec must bet set to True if any of the fields in the spec are set to non-default values.

createTime string: Time the AccessPolicy was created in UTC.
description string: Description of the ServicePerimeter and its use. Does not affect behavior.
name string: Resource name for the ServicePerimeter. The shortname component must begin with a letter and only include alphanumeric and ‘’. Format: accessPolicies/{policy_id}/servicePerimeters/{short_name}
parent string: The AccessPolicy this ServicePerimeter lives in. Format: accessPolicies/{policy_id}
perimeterType string: Specifies the type of the Perimeter. There are two types: regular and bridge. Regular Service Perimeter contains resources, access levels, and restricted services. Every resource can be in at most ONE regular Service Perimeter. In addition to being in a regular service perimeter, a resource can also be in zero or more perimeter bridges. A perimeter bridge only contains resources. Cross project operations are permitted if all effected resources share some perimeter (whether bridge or regular). Perimeter Bridge does not contain access levels or services: those are governed entirely by the regular perimeter that resource is in. Perimeter Bridges are typically useful when building more complex topologies with many independent perimeters that need to share some data with a common perimeter, but should not be able to share data among themselves.
spec ServicePerimeterSpec: 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 useExplicitDryRunSpec flag is set. Structure is documented below.
status ServicePerimeterStatus: ServicePerimeter configuration. Specifies sets of resources, restricted services and access levels that determine perimeter content and boundaries. Structure is documented below.
title string: Human readable title. Must be unique within the Policy.
updateTime string: Time the AccessPolicy was updated in UTC.
useExplicitDryRunSpec boolean: 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. useExplicitDryRunSpec must bet set to True if any of the fields in the spec are set to non-default values.

create_time str: Time the AccessPolicy was created in UTC.
description str: Description of the ServicePerimeter and its use. Does not affect behavior.
name str: Resource name for the ServicePerimeter. The shortname component must begin with a letter and only include alphanumeric and ‘’. Format: accessPolicies/{policy_id}/servicePerimeters/{short_name}
parent str: The AccessPolicy this ServicePerimeter lives in. Format: accessPolicies/{policy_id}
perimeter_type str: Specifies the type of the Perimeter. There are two types: regular and bridge. Regular Service Perimeter contains resources, access levels, and restricted services. Every resource can be in at most ONE regular Service Perimeter. In addition to being in a regular service perimeter, a resource can also be in zero or more perimeter bridges. A perimeter bridge only contains resources. Cross project operations are permitted if all effected resources share some perimeter (whether bridge or regular). Perimeter Bridge does not contain access levels or services: those are governed entirely by the regular perimeter that resource is in. Perimeter Bridges are typically useful when building more complex topologies with many independent perimeters that need to share some data with a common perimeter, but should not be able to share data among themselves.
spec Dict[ServicePerimeterSpec]: 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 useExplicitDryRunSpec flag is set. Structure is documented below.
status Dict[ServicePerimeterStatus]: ServicePerimeter configuration. Specifies sets of resources, restricted services and access levels that determine perimeter content and boundaries. Structure is documented below.
title str: Human readable title. Must be unique within the Policy.
update_time str: Time the AccessPolicy was updated in UTC.
use_explicit_dry_run_spec 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. useExplicitDryRunSpec must bet set to True if any of the fields in the spec are set to non-default values.

Supporting Types

ServicePerimeterSpec

See the input and output API doc for this type.

AccessLevels List<string>: A list of AccessLevel resource names that allow resources within the ServicePerimeter to be accessed from the internet. AccessLevels listed must be in the same policy as this ServicePerimeter. Referencing a nonexistent AccessLevel is a syntax error. If no AccessLevel names are listed, resources within the perimeter can only be accessed via GCP calls with request origins within the perimeter. For Service Perimeter Bridge, must be empty. Format: accessPolicies/{policy_id}/accessLevels/{access_level_name}
Resources List<string>: A list of GCP resources that are inside of the service perimeter. Currently only projects are allowed. Format: projects/{project_number}
RestrictedServices List<string>: GCP services that are subject to the Service Perimeter restrictions. Must contain a list of services. For example, if storage.googleapis.com is specified, access to the storage buckets inside the perimeter must meet the perimeter’s access restrictions.
VpcAccessibleServices ServicePerimeterSpecVpcAccessibleServicesArgs: Specifies how APIs are allowed to communicate within the Service Perimeter. Structure is documented below.

AccessLevels []string: A list of AccessLevel resource names that allow resources within the ServicePerimeter to be accessed from the internet. AccessLevels listed must be in the same policy as this ServicePerimeter. Referencing a nonexistent AccessLevel is a syntax error. If no AccessLevel names are listed, resources within the perimeter can only be accessed via GCP calls with request origins within the perimeter. For Service Perimeter Bridge, must be empty. Format: accessPolicies/{policy_id}/accessLevels/{access_level_name}
Resources []string: A list of GCP resources that are inside of the service perimeter. Currently only projects are allowed. Format: projects/{project_number}
RestrictedServices []string: GCP services that are subject to the Service Perimeter restrictions. Must contain a list of services. For example, if storage.googleapis.com is specified, access to the storage buckets inside the perimeter must meet the perimeter’s access restrictions.
VpcAccessibleServices ServicePerimeterSpecVpcAccessibleServices: Specifies how APIs are allowed to communicate within the Service Perimeter. Structure is documented below.

accessLevels string[]: A list of AccessLevel resource names that allow resources within the ServicePerimeter to be accessed from the internet. AccessLevels listed must be in the same policy as this ServicePerimeter. Referencing a nonexistent AccessLevel is a syntax error. If no AccessLevel names are listed, resources within the perimeter can only be accessed via GCP calls with request origins within the perimeter. For Service Perimeter Bridge, must be empty. Format: accessPolicies/{policy_id}/accessLevels/{access_level_name}
resources string[]: A list of GCP resources that are inside of the service perimeter. Currently only projects are allowed. Format: projects/{project_number}
restrictedServices string[]: GCP services that are subject to the Service Perimeter restrictions. Must contain a list of services. For example, if storage.googleapis.com is specified, access to the storage buckets inside the perimeter must meet the perimeter’s access restrictions.
vpcAccessibleServices ServicePerimeterSpecVpcAccessibleServices: Specifies how APIs are allowed to communicate within the Service Perimeter. Structure is documented below.

accessLevels List[str]: A list of AccessLevel resource names that allow resources within the ServicePerimeter to be accessed from the internet. AccessLevels listed must be in the same policy as this ServicePerimeter. Referencing a nonexistent AccessLevel is a syntax error. If no AccessLevel names are listed, resources within the perimeter can only be accessed via GCP calls with request origins within the perimeter. For Service Perimeter Bridge, must be empty. Format: accessPolicies/{policy_id}/accessLevels/{access_level_name}
resources List[str]: A list of GCP resources that are inside of the service perimeter. Currently only projects are allowed. Format: projects/{project_number}
restrictedServices List[str]: GCP services that are subject to the Service Perimeter restrictions. Must contain a list of services. For example, if storage.googleapis.com is specified, access to the storage buckets inside the perimeter must meet the perimeter’s access restrictions.
vpcAccessibleServices Dict[ServicePerimeterSpecVpcAccessibleServices]: Specifies how APIs are allowed to communicate within the Service Perimeter. Structure is documented below.

ServicePerimeterSpecVpcAccessibleServices

See the input and output API doc for this type.

AllowedServices List<string>: The list of APIs usable within the Service Perimeter. Must be empty unless enableRestriction is True.
EnableRestriction bool: Whether to restrict API calls within the Service Perimeter to the list of APIs specified in ‘allowedServices’.

AllowedServices []string: The list of APIs usable within the Service Perimeter. Must be empty unless enableRestriction is True.
EnableRestriction bool: Whether to restrict API calls within the Service Perimeter to the list of APIs specified in ‘allowedServices’.

allowedServices string[]: The list of APIs usable within the Service Perimeter. Must be empty unless enableRestriction is True.
enableRestriction boolean: Whether to restrict API calls within the Service Perimeter to the list of APIs specified in ‘allowedServices’.

allowedServices List[str]: The list of APIs usable within the Service Perimeter. Must be empty unless enableRestriction is True.
enableRestriction bool: Whether to restrict API calls within the Service Perimeter to the list of APIs specified in ‘allowedServices’.

ServicePerimeterStatus

See the input and output API doc for this type.

AccessLevels List<string>: A list of AccessLevel resource names that allow resources within the ServicePerimeter to be accessed from the internet. AccessLevels listed must be in the same policy as this ServicePerimeter. Referencing a nonexistent AccessLevel is a syntax error. If no AccessLevel names are listed, resources within the perimeter can only be accessed via GCP calls with request origins within the perimeter. For Service Perimeter Bridge, must be empty. Format: accessPolicies/{policy_id}/accessLevels/{access_level_name}
Resources List<string>: A list of GCP resources that are inside of the service perimeter. Currently only projects are allowed. Format: projects/{project_number}
RestrictedServices List<string>: GCP services that are subject to the Service Perimeter restrictions. Must contain a list of services. For example, if storage.googleapis.com is specified, access to the storage buckets inside the perimeter must meet the perimeter’s access restrictions.
VpcAccessibleServices ServicePerimeterStatusVpcAccessibleServicesArgs: Specifies how APIs are allowed to communicate within the Service Perimeter. Structure is documented below.

AccessLevels []string: A list of AccessLevel resource names that allow resources within the ServicePerimeter to be accessed from the internet. AccessLevels listed must be in the same policy as this ServicePerimeter. Referencing a nonexistent AccessLevel is a syntax error. If no AccessLevel names are listed, resources within the perimeter can only be accessed via GCP calls with request origins within the perimeter. For Service Perimeter Bridge, must be empty. Format: accessPolicies/{policy_id}/accessLevels/{access_level_name}
Resources []string: A list of GCP resources that are inside of the service perimeter. Currently only projects are allowed. Format: projects/{project_number}
RestrictedServices []string: GCP services that are subject to the Service Perimeter restrictions. Must contain a list of services. For example, if storage.googleapis.com is specified, access to the storage buckets inside the perimeter must meet the perimeter’s access restrictions.
VpcAccessibleServices ServicePerimeterStatusVpcAccessibleServices: Specifies how APIs are allowed to communicate within the Service Perimeter. Structure is documented below.

accessLevels string[]: A list of AccessLevel resource names that allow resources within the ServicePerimeter to be accessed from the internet. AccessLevels listed must be in the same policy as this ServicePerimeter. Referencing a nonexistent AccessLevel is a syntax error. If no AccessLevel names are listed, resources within the perimeter can only be accessed via GCP calls with request origins within the perimeter. For Service Perimeter Bridge, must be empty. Format: accessPolicies/{policy_id}/accessLevels/{access_level_name}
resources string[]: A list of GCP resources that are inside of the service perimeter. Currently only projects are allowed. Format: projects/{project_number}
restrictedServices string[]: GCP services that are subject to the Service Perimeter restrictions. Must contain a list of services. For example, if storage.googleapis.com is specified, access to the storage buckets inside the perimeter must meet the perimeter’s access restrictions.
vpcAccessibleServices ServicePerimeterStatusVpcAccessibleServices: Specifies how APIs are allowed to communicate within the Service Perimeter. Structure is documented below.

accessLevels List[str]: A list of AccessLevel resource names that allow resources within the ServicePerimeter to be accessed from the internet. AccessLevels listed must be in the same policy as this ServicePerimeter. Referencing a nonexistent AccessLevel is a syntax error. If no AccessLevel names are listed, resources within the perimeter can only be accessed via GCP calls with request origins within the perimeter. For Service Perimeter Bridge, must be empty. Format: accessPolicies/{policy_id}/accessLevels/{access_level_name}
resources List[str]: A list of GCP resources that are inside of the service perimeter. Currently only projects are allowed. Format: projects/{project_number}
restrictedServices List[str]: GCP services that are subject to the Service Perimeter restrictions. Must contain a list of services. For example, if storage.googleapis.com is specified, access to the storage buckets inside the perimeter must meet the perimeter’s access restrictions.
vpcAccessibleServices Dict[ServicePerimeterStatusVpcAccessibleServices]: Specifies how APIs are allowed to communicate within the Service Perimeter. Structure is documented below.

ServicePerimeterStatusVpcAccessibleServices

See the input and output API doc for this type.

AllowedServices List<string>: The list of APIs usable within the Service Perimeter. Must be empty unless enableRestriction is True.
EnableRestriction bool: Whether to restrict API calls within the Service Perimeter to the list of APIs specified in ‘allowedServices’.

AllowedServices []string: The list of APIs usable within the Service Perimeter. Must be empty unless enableRestriction is True.
EnableRestriction bool: Whether to restrict API calls within the Service Perimeter to the list of APIs specified in ‘allowedServices’.

allowedServices string[]: The list of APIs usable within the Service Perimeter. Must be empty unless enableRestriction is True.
enableRestriction boolean: Whether to restrict API calls within the Service Perimeter to the list of APIs specified in ‘allowedServices’.

allowedServices List[str]: The list of APIs usable within the Service Perimeter. Must be empty unless enableRestriction is True.
enableRestriction bool: Whether to restrict API calls within the Service Perimeter to the list of APIs specified in ‘allowedServices’.

Package Details

Repository: https://github.com/pulumi/pulumi-gcp
License: Apache-2.0
Notes: This Pulumi package is based on the google-beta Terraform Provider.

The Pulumi Platform

Get Started

Migrate to Pulumi

Solutions for All Teams and Engineers

Any Code

Any Cloud

ServicePerimeter

Create a ServicePerimeter Resource

ServicePerimeter Resource Properties

Inputs

Outputs

Look up an Existing ServicePerimeter Resource

Supporting Types

ServicePerimeterSpec

ServicePerimeterSpecVpcAccessibleServices

ServicePerimeterStatus

ServicePerimeterStatusVpcAccessibleServices

Package Details

On This Page