Page MenuHomePhabricator

Lock Almanac networks, and allow Almanac domain namespaces to be locked
Closed, ResolvedPublic


A risk of defining Phabricator clusters within Phabricator is that anyone with permission to edit said services in Almanac can adjust the cluster -- at best taking the cluster down, and at worst, e.g., configuring the master database to replicate to some external, attacker-controlled device (this won't be possible for a long time, but similar attacks will be possible sooner.).

I think the best approach for this is to allow services to be locked, forbidding all edits from the web UI. So you configure a cluster service, lock it from the CLI, and then can use it safely. These locks could be soft to avoid getting in the way too much (you can use unlocked services, we just warn you that you should lock services in use).

Locking a service should lock all connected bindings, interfaces and devices. Interfaces and devices may need to hold a lock-level: if a device is part of several services, all services must be unlocked before the device can be modified.

We need this (or some similar tech) for Phacility to prevent installs from going into Almanac and breaking their own cluster by changing things around randomly. It's possible we could accomplish this more cleanly in the long run with Spaces or maybe just policies, but having an extra layer of immutability won't hurt even when those are running.

Event Timeline

epriestley claimed this task.
epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley moved this task from Backlog to v0 Closed Beta on the Phacility board.
epriestley added subscribers: talshiri, chad, aderumier and 4 others.

I need to get Networks in on this too.

The remaining work is:

  • Networks should also lock. This doesn't really matter since they don't do anything important right now.
  • We should prevent installs from creating services in the "" domain, because they could create services which would collide with services we later attach to the instance. This isn't something you can blunder into, though, and is easily resolved manually at small scales.
epriestley renamed this task from Allow Almanac services to be locked to Lock Almanac networks, and allow Almanac domain namespaces to be locked.Feb 1 2015, 1:03 AM
epriestley moved this task from v0 Closed Beta to Do After Launch on the Phacility board.
epriestley lowered the priority of this task from Normal to Low.Feb 27 2015, 12:53 AM

The urgency of fixing this is dramatically reduced by Almanac being a prototype and installs not having access to prototypes so this can be punted to the horizon.

epriestley edited projects, added Almanac (v2); removed Almanac.

In the Phacility case, I can also just give these networks a "no one" edit policy, but still need to do the namespace locking.

I also think the current per-service and per-device granular locking might be better off as a cluster.locked global configuration which prevents creating or editing anything touching a cluster service, so I may pursue that.

As written, it is insufficient to prevent services from being added, and Diffusion's default behavior is to randomly select a cluster repository host if any are available, so adding new services counts. We can lock the add permission for cluster services to "no one", but then the mechanism isn't useful in the general case.

We could also implicitly lock new services if any existing service is locked, but this feels non-obvious / non-general. It would be better to lock the service class as a whole, instead.