Allow Almanac services to be locked

Summary:
Fixes T6741. This allows Almanac services to be locked from the CLI. Locked services (and their bindings, interfaces and devices) can not be edited. This serves two similar use cases:

  - For normal installs, you can protect cluster configuration from an attacker who compromises an account (or generally harden services which are intended to be difficult to edit).
  - For Phacility, we can lock externally-managed instance cluster configuration without having to pull any spooky tricks.

Test Plan:
  - Locked and unlocked services.
  - Verified locking a service locks connected properties, bindings, binding properties, interfaces, devices, and device properties.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T6741

Differential Revision: https://secure.phabricator.com/D11006

src/docs/user/configuration/cluster.diviner

@@ -0,0 +1,31 @@
+@title User Guide: Phabricator Clusters
+@group config
+
+Guide on scaling Phabricator across multiple machines, for large installs.
+
+Overview
+========
+
+IMPORTANT: Phabricator clustering is in its infancy and does not work at all
+yet. This document is mostly a placeholder.
+
+Locking Services
+================
+
+Because cluster configuration is defined in Phabricator itself, an attacker
+who compromises an account that can edit the cluster definition has significant
+power. For example, the attacker might be able to configure Phabricator to
+replicate the database to a server they control.
+
+To mitigate this attack, services in Almanac can be locked to prevent them
+from being edited from the web UI. An attacker would then need significantly
+greater access (to the CLI, or directly to the database) in order to change
+the cluster configuration.
+
+You should normally keep cluster services in a locked state, and unlock them
+only to edit them. Once you're finished making changes, lock the service again.
+The web UI will warn you when you're viewing an unlocked cluster service, as
+a reminder that you should lock it again once you're finished editing.
+
+For details on how to lock and unlock a service, see
+@{article:Almanac User Guide}.

src/docs/user/userguide/almanac.diviner

@@ -0,0 +1,40 @@
+@title Almanac User Guide
+@group userguide
+
+Using Almanac to manage services.
+
+= Overview =
+
+IMPORTANT: Almanac is a prototype application. See
+@{article:User Guide: Prototype Applications}.
+
+Locking and Unlocking Services
+==============================
+
+Services can be locked to prevent edits from the web UI. This primarily hardens
+Almanac against attacks involving account compromise. Notably, locking cluster
+services prevents an attacker from modifying the Phabricator cluster definition.
+For more details on this scenario, see
+@{article:User Guide: Phabricator Clusters}.
+
+Beyond hardening cluster definitions, you might also want to lock a service to
+prevent accidental edits.
+
+To lock a service, run:
+
+  phabricator/ $ ./bin/almanac lock <service>
+
+To unlock a service later, run:
+
+  phabricator/ $ ./bin/almanac unlock <service>
+
+Locking a service also locks all of the service's bindings and properties, as
+well as the devices connected to the service. Generally, no part of the
+service definition can be modified while it is locked.
+
+Devices (and their properties) will remain locked as long as they are bound to
+at least one locked service. To edit a device, you'll need to unlock all the
+services it is bound to.
+
+Locked services and devices will show that they are locked in the web UI, and
+editing options will be unavailable.