Classes
AccessLevel
An AccessLevel is a label that can be applied to requests to Google Cloud
services, along with a list of requirements necessary for the label to be
applied.
AccessPolicy
AccessPolicy is a container for AccessLevels (which define the necessary
attributes to use Google Cloud services) and ServicePerimeters (which
define regions of services able to freely pass data within a perimeter). An
access policy is globally visible within an organization, and the
restrictions it specifies apply to all projects within an organization.
BasicLevel
BasicLevel is an AccessLevel using a set of recommended features.
BasicLevel.Types
Container for nested types declared in the BasicLevel message type.
Condition
A condition necessary for an AccessLevel to be granted. The Condition is an
AND over its fields. So a Condition is true if: 1) the request IP is from one
of the listed subnetworks AND 2) the originating device complies with the
listed device policy AND 3) all listed access levels are granted AND 4) the
request was sent at a time allowed by the DateTimeRestriction.
CustomLevel
CustomLevel is an AccessLevel using the Cloud Common Expression Language
to represent the necessary conditions for the level to apply to a request.
See CEL spec at: https://github.com/google/cel-spec
DevicePolicy
DevicePolicy specifies device specific restrictions necessary to acquire a
given access level. A DevicePolicy specifies requirements for requests from
devices to be granted access levels, it does not do any enforcement on the
device. DevicePolicy acts as an AND over all specified fields, and each
repeated field is an OR over its elements. Any unset fields are ignored. For
example, if the proto is { os_type : DESKTOP_WINDOWS, os_type :
DESKTOP_LINUX, encryption_status: ENCRYPTED}, then the DevicePolicy will be
true for requests originating from encrypted Linux desktops and encrypted
Windows desktops.
OsConstraint
A restriction on the OS type and version of devices making requests.
ServicePerimeter
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 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.
ServicePerimeter.Types
Container for nested types declared in the ServicePerimeter message type.
ServicePerimeterConfig
ServicePerimeterConfig specifies a set of Google Cloud resources that
describe specific Service Perimeter configuration.
ServicePerimeterConfig.Types
Container for nested types declared in the ServicePerimeterConfig message type.
ServicePerimeterConfig.Types.VpcAccessibleServices
Specifies how APIs are allowed to communicate within the Service Perimeter.
Enums
AccessLevel.LevelOneofCase
Enum of possible cases for the "level" oneof.
BasicLevel.Types.ConditionCombiningFunction
Options for how the conditions list should be combined to determine if
this AccessLevel is applied. Default is AND.
ServicePerimeter.Types.PerimeterType
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 toplogies with many independent perimeters that need to share some data with a common perimeter, but should not be able to share data among themselves.