.. _device-identity: *************** Device Identity *************** Every device that connects to a Bowtie Controller has its own identity. A Controller uses that identity to decide what the device may reach, and the same access policies apply whether a device belongs to a person or runs on its own as a server or service. How a device gets its identity ============================== When a device first connects, the Bowtie :doc:`client ` on that device creates a unique cryptographic key. It keeps the private key in the operating system's secure credential store and sends only the public key to the Controller. The private key never leaves the device. The Controller records the device's public key and assigns the device a unique address on the Bowtie network. Each device receives its own IPv6 range and an IPv4 address, and those addresses stay with the device. Policies and logs refer to the device by this stable identity. Because the client creates the key during the first connection, an operator does not have to issue or distribute a credential by hand. A new machine enrolls the same way whether it is a laptop or an unattended server. Devices without a user ====================== A device does not have to belong to a person. A server, a build agent, or a Controller itself can hold its own identity with no user assigned to it. You can then apply access policy to machine-to-machine traffic in the same way you apply it to people. - **Organization-owned devices.** A device can be owned by the organization rather than by a user. Controllers and shared infrastructure are represented this way. - **Unattended enrollment.** A server with no interactive login can enroll from a :ref:`cloud-init ` configuration at first boot, which suits continuous integration runners and other automation. Device lifecycle ================ A device moves through a small set of states that you manage from the Controller: - **Pending.** The device has connected but is not yet approved. - **Accepted.** The device is approved and receives its address and access. - **Rejected.** The device is denied access and cannot reach resources on the network. The Controller records when each device was last seen. You can configure Bowtie to deactivate or remove devices that have been inactive for a chosen length of time, so that stale machines do not keep access. Identities for automation ========================= Software that calls the Controller :ref:`API `, such as a Terraform or Pulumi pipeline, authenticates with a service-account :ref:`API key ` rather than a device key. You can give an API key an expiry date and revoke it at any time. Keep API keys in a secrets manager and pass them to your automation through environment variables, as shown under :ref:`terraform-provider`.