********
Glossary
********

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

     #. 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 :ref:`aws` and :ref:`azure`.

     #. As a raw operating system disk image file.
	This method is suitable for use within environments such as :ref:`vmware`, :ref:`proxmox`, and KVM-based environments like ``libvirt`` or LXC that require :ref:`qcow` disk images.

     #. As Kubernetes Helm Manifests.
     To properly support deployments in Kubernetes runtimes, a Helm chart that manages `KubeVirt virtual machines <https://kubevirt.io/>`_ is still under development/experimental.

   policy
     *Policies* represent the mapping between a given set of :term:`sources <source>` 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 :ref:`org-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 :term:`policy` will honor, including options like protocol, address, or port.

   resource group
     Resource groups aggregate individual :term:`resources <resource>` into collections of related resources.
     A :term:`policy` addresses resource groups rather than individual :term:`resources <resource>`.

   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 :term:`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 :term:`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 :ref:`org-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 :ref:`org-devices` page,

     - Or device *groups* comprised of many individual devices.