This document describes bastion hosts, which serve as gatekeepers for operational access to the [[ phacility_cluster | Phacility Cluster ]]. Here and elsewhere, "operational access" refers to deploying, administrating, and managing hosts, services, and data in the cluster. Overview ====== The Phacility cluster runs in a VPC. Most devices in the cluster do not have external interfaces, and operational access to the VPC (for example, deploying and upgrading hosts) occurs through a bastion host. The bastion serves as an SSH proxy that authorizes users to act within the cluster. This is a common way to configure access to a private network, see [[ http://en.wikipedia.org/wiki/Bastion_host | Bastion Host]] on Wikipedia. Using a bastion helps protect the cluster from external threats: inbound operational traffic is limited to a single tightly-controlled gateway. Using a bastion also helps protect the cluster from internal threats, like a compromised employee account or rogue staff member. The bastion identifies and authorizes the connecting user, but also authorizes the commands they are executing. Operations staff can be given limited access to the cluster or selective access to specific instances. Using the Bastion ======= Some light operational work can be performed from the instance administration UI on `admin.phacility.com`. Most operational work occurs via the bastion proper, via the [[ phacility_cluster/cli | CLI Tools ]]. Operational Access Transparency Report ======= Last updated Feb 2015. This is a transparency report which categorizes operational access levels in the Phacility cluster. //As we currently have three employees, this disclosure isn't very meaningful in its current form, but we believe transparency about access control is important and expect this report will reflect a disciplined approach to access control as we grow.// Access is affected by both policy controls (which describe when access is acceptable) and technical controls (which prevent access). Policy controls can remedy improper access, but can not prevent it. Technical controls prevent access. Wherever possible, we use technical controls. At the highest level, a minimum number of senior staff have full technical access in order to recover from disasters and remedy problems in the access control software itself. Operational staff currently have these levels of access to the cluster: | Access Level | Description | |---|---| | Master | Full technical access to the cluster; access restricted by policy controls. | | None | No access to any customer data or cluster operations. | This table summarizes staff access levels: | Access Level | Title | Headcount | Notes | |---|---|---|---| | Master | CEO | 1 | The CEO currently has significant operational responsibilities. | | CTO | 1 | The CTO currently has significant operational responsibilities. | None | VP of Product | 1 | These employees have no special access.

This document describes bastion hosts, which serve as gatekeepers for operational access to the [[ phacility_cluster | Phacility Cluster ]]. Here and elsewhere, "operational access" refers to deploying, administrating, and managing hosts, services, and data in the cluster. Overview ====== The Phacility cluster runs in a VPC. Most devices in the cluster do not have external interfaces, and operational access to the VPC (for example, deploying and upgrading hosts) occurs through a bastion host. The bastion serves as an SSH proxy that authorizes users to act within the cluster. This is a common way to configure access to a private network, see [[ http://en.wikipedia.org/wiki/Bastion_host | Bastion Host]] on Wikipedia. Using a bastion helps protect the cluster from external threats: inbound operational traffic is limited to a single tightly-controlled gateway. Using a bastion also helps protect the cluster from internal threats, like a compromised employee account or rogue staff member. The bastion identifies and authorizes the connecting user, but also authorizes the commands they are executing. Operations staff can be given limited access to the cluster or selective access to specific instances. Using the Bastion ======= Some light operational work can be performed from the instance administration UI on `admin.phacility.com`. Most operational work occurs via the bastion proper, via the [[ phacility_cluster/cli | CLI Tools ]]. Operational Access Transparency Report ======= Last updated Feb 2015. This is a transparency report which categorizes operational access levels in the Phacility cluster. //As we currently have three employees, this disclosure isn't very meaningful in its current form, but we believe transparency about access control is important and expect this report will reflect a disciplined approach to access control as we grow.// Access is affected by both policy controls (which describe when access is acceptable) and technical controls (which prevent access). Policy controls can remedy improper access, but can not prevent it. Technical controls prevent access. Wherever possible, we use technical controls. At the highest level, a minimum number of senior staff have full technical access in order to recover from disasters and remedy problems in the access control implementation itself. Operational staff currently have these levels of access to the cluster: | Access Level | Description | |---|---| | Master | Full technical access to the cluster; access restricted by policy controls. | | None | No access to any customer data or cluster operations. | This table summarizes staff access levels: | Access Level | Title | Headcount | Notes | |---|---|---|---| | Master | CEO | 1 | The CEO currently has significant operational responsibilities. | | CTO | 1 | The CTO currently has significant operational responsibilities. | None | VP of Product | 1 | These employees have no special access.

This document describes bastion hosts, which serve as gatekeepers for operational access to the [[ phacility_cluster | Phacility Cluster ]]. Here and elsewhere, "operational access" refers to deploying, administrating, and managing hosts, services, and data in the cluster. Overview ====== The Phacility cluster runs in a VPC. Most devices in the cluster do not have external interfaces, and operational access to the VPC (for example, deploying and upgrading hosts) occurs through a bastion host. The bastion serves as an SSH proxy that authorizes users to act within the cluster. This is a common way to configure access to a private network, see [[ http://en.wikipedia.org/wiki/Bastion_host | Bastion Host]] on Wikipedia. Using a bastion helps protect the cluster from external threats: inbound operational traffic is limited to a single tightly-controlled gateway. Using a bastion also helps protect the cluster from internal threats, like a compromised employee account or rogue staff member. The bastion identifies and authorizes the connecting user, but also authorizes the commands they are executing. Operations staff can be given limited access to the cluster or selective access to specific instances. Using the Bastion ======= Some light operational work can be performed from the instance administration UI on `admin.phacility.com`. Most operational work occurs via the bastion proper, via the [[ phacility_cluster/cli | CLI Tools ]]. Operational Access Transparency Report ======= Last updated Feb 2015. This is a transparency report which categorizes operational access levels in the Phacility cluster. //As we currently have three employees, this disclosure isn't very meaningful in its current form, but we believe transparency about access control is important and expect this report will reflect a disciplined approach to access control as we grow.// Access is affected by both policy controls (which describe when access is acceptable) and technical controls (which prevent access). Policy controls can remedy improper access, but can not prevent it. Technical controls prevent access. Wherever possible, we use technical controls. At the highest level, a minimum number of senior staff have full technical access in order to recover from disasters and remedy problems in the access control softwareimplementation itself. Operational staff currently have these levels of access to the cluster: | Access Level | Description | |---|---| | Master | Full technical access to the cluster; access restricted by policy controls. | | None | No access to any customer data or cluster operations. | This table summarizes staff access levels: | Access Level | Title | Headcount | Notes | |---|---|---|---| | Master | CEO | 1 | The CEO currently has significant operational responsibilities. | | CTO | 1 | The CTO currently has significant operational responsibilities. | None | VP of Product | 1 | These employees have no special access.