Glossary

appliance

The Bowtie operating system image. We provide appliances in three forms:

  1. As an image ID in public clouds where instances may be created based upon the base image template. This is the means for distribution in public clouds such as AWS and Azure.

  2. As a raw operating system disk image file. This method is suitable for use within environments such as VMWare, Proxmox, and KVM-based environments like libvirt or LXC that require qcow2 disk images.

#. As Kubernetes Helm Manifests. To properly support deployments in Kubernetes runtimes, a Helm chart that manages KubeVirt virtual machines is still under development/experimental.

policy

Policies represent the mapping between a given set of sources or principals, such as a device, user, or group, the desired resource, such as a specific address or CIDR network, and the access decision between those two entities. For example, you may wish to grant access to a specific web server within a private network to any user authenticated by your single sign-on provider.

Policies offer a comprehensive set of criteria to apply when making access decisions. They may be configured through Access Policies or the Bowtie Control Plane API.

resource

A resource identifies some addressable endpoint routable from somewhere within the network that Bowtie controls access to. Resources can target a variety of criteria that a policy will honor, including options like protocol, address, or port.

resource group

Resource groups aggregate individual resources into collections of related resources. A policy addresses resource groups rather than individual resources.

site

A Bowtie site can best be thought of in a similar sense as a public cloud region: a place where a Bowtie Controller will operate adjacent to other resources. In this example, for a presence in AWS, one site may be called US West 2, while another site may be called US East 1.

For on-premise deployments, you may demarcate sites based upon their regional locality as well (“Arizona Datacenter” versus “Colorado Datacenter”) or instead based upon resiliency or fail-over requirements (“Arizona Zone 1” versus “Arizona Zone 2”).

For each site, one or more Bowtie Controllers should reference a singular site ID. This value should be passed in via environment variables in files within /etc/bowtie-server.d/ on cloud or virtual machine appliances or as a plain SITE_ID in containers, which is captured as the Helm value site_id.

Site IDs should be provided as UUID4-formatted strings.

site range

Site ranges are the subnets that any given site may present itself as able to serve.

For example, if the running Controller can route requests to the private subnet 10.100.150.0/24 and you would like to expose this private subnet to authenticated clients, adding it as a site range to the Controller’s configuration enables connectivity from any authenticated client with a matching policy.

source

Sources are used in policies to make access decisions based on certain criteria, including:

  • All accepted devices, which indicates all devices in the Accepted state on the Organization Devices page,

  • All authenticated users that have successfully logged in to a Controller’s control plane web frontend using any provided identify providers,

  • Users present in the control plane, whether authenticated or not,

  • User groups comprised of individual users,

  • Individual devices drawn from the Organization Devices page,

  • Or device groups comprised of many individual devices.