Differential D15696 Diff 37832 src/docs/user/cluster/cluster.diviner

Changeset View

Standalone View

src/docs/user/cluster/cluster.diviner

	Show All 24 Lines

	The remainder of this document summarizes how to add redundancy to each			The remainder of this document summarizes how to add redundancy to each
	service and where your efforts are likely to have the greatest impact.			service and where your efforts are likely to have the greatest impact.

	For additional guidance on setting up a cluster, see "Overlaying Services"			For additional guidance on setting up a cluster, see "Overlaying Services"
	and "Cluster Recipes" at the bottom of this document.			and "Cluster Recipes" at the bottom of this document.


				Preparing for Clustering
				========================

				To begin deploying Phabricator in cluster mode, set up `cluster.addresses`
				in your configuration.

				This option should contain a list of network addess blocks which are considered
				to be part of the cluster. Hosts in this list are allowed to bend (or even
				break) some of the security and policy rules when they make requests to other
				hosts in the cluster, so this list should be as small as possible. See "Cluster
				Whitelist Security" below for discussion.

				If you are deploying hardware in EC2, a reasonable approach is to launch a
				dedicated Phabricator VPC, whitelist the whole VPC as a Phabricator cluster,
				and then deploy only Phabricator services into that VPC.

				If you have additional auxiliary hosts which run builds and tests via Drydock,
				you should //not// include them in the cluster address definition. For more
				detailed discussion of the Drydock security model, see @{Drydock User Guide:
				Security}.

				Most other clustering features will not work until you define a cluster by
				configuring `cluster.addresses`.


				Cluster Whitelist Security
				========================

				When you configure `cluster.addresses`, you should keep the list of trusted
				cluster hosts as small as possible. Hosts on this list gain additional
				capabilities, including these:

				Trusted HTTP Headers: Normally, Phabricator distrusts the load balancer
				HTTP headers `X-Forwarded-For` and `X-Forwarded-Proto` because they may be
				client-controlled and can be set to arbitrary values by an attacker if no load
				balancer is deployed. In particular, clients can set `X-Forwarded-For` to any
				value and spoof traffic from arbitrary remotes.

				These headers are trusted when they are received from a host on the cluster
				address whitelist. This allows requests from cluster loadbalancers to be
				interpreted correctly by default without requiring additional custom code or
				configuration.

				Intracluster HTTP: Requests from cluster hosts are not required to use
				HTTPS, even if `security.require-https` is enabled, because it is common to
				terminate HTTPS on load balancers and use plain HTTP for requests within a
				cluster.

				Special Authentication Mechanisms: Cluster hosts are allowed to connect to
				other cluster hosts with "root credentials", and to impersonate any user
				account.

				The use of root credentials is required because the daemons must be able to
				bypass policies in order to function properly: they need to send mail about
				private conversations and import commits in private repositories.

				The ability to impersonate users is required because SSH nodes must receive,
				interpret, modify, and forward SSH traffic. They can not use the original
				credentials to do this because SSH authentication is asymmetric and they do not
				have the user's private key. Instead, they use root credentials and impersonate
				the user within the cluster.

				These mechanisms are still authenticated (and use asymmetric keys, like SSH
				does), so access to a host in the cluster address block does not mean that an
				chadUnsubmitted Not Done Inline Actions accessing? or access to? chad: accessing? or access to?
				attacker can immediately compromise the cluster. However, an overbroad cluster
				address whitelist may give an attacker who gains some access additional tools
				to escalate access.

				Note that if an attacker gains access to an actual cluster host, these extra
				powers are largely moot. Most cluster hosts must be able to connect to the
				master database to function properly, so the attacker will just do that and
				freely read or modify whatever data they want.


	Cluster: Databases			Cluster: Databases
	=================			=================

	Configuring multiple database hosts is moderately complex, but normally has the			Configuring multiple database hosts is moderately complex, but normally has the
	highest impact on availability and resistance to data loss. This is usually the			highest impact on availability and resistance to data loss. This is usually the
	most important service to make redundant if your focus is on availability and			most important service to make redundant if your focus is on availability and
	disaster recovery.			disaster recovery.

	Configuring replicas allows Phabricator to run in read-only mode if you lose			Configuring replicas allows Phabricator to run in read-only mode if you lose
	the master, and to quickly promote the replica as a replacement.			the master and to quickly promote the replica as a replacement.

	For details, see @{article:Cluster: Databases}.			For details, see @{article:Cluster: Databases}.


	Cluster: Repositories			Cluster: Repositories
	=====================			=====================

	Configuring multiple repository hosts is complex, but is required before you			Configuring multiple repository hosts is complex, but is required before you
	▲ Show 20 Lines • Show All 131 Lines • Show Last 20 Lines