It works the same for a Backdrop site as for a Drupal one, the role does not care which core sits on the platform; and the one thing to say out loud before you hand the key over is that a valet key is not a read-only key. A Site operator still clones and migrates, which is real work on real copies, so if what the auditor wants is a login which can only look, the panel has no such role today; a login with no role at all sees nothing, which is safe and useless in equal measure.
Which is of course the next question: the auditor’s key, a login which opens the door and touches nothing, and whether the task logs alone are enough of a view or the Backups list has to be on it too. Until somebody asks for it properly, the six keys are laid out on the logins and roles page in a matrix with seven columns, which is one column more than the ring has hooks and roughly the number of times a year you will open it, and the commands for the person who cuts the keys are on the panel roles page, next to a small table of what to answer when a tenant asks for the engine bay key for their valet.
Then the two shell keys, which an earlier post called the boot key and the engine bay key: the ordinary extra login per Client, built by itself the moment a Client owns a site, for files and themes and nothing underneath; and the platform developer login your host switches on per Client, whole codebases, Composer and the platform’s own Drush. Both hang off a Client, never off a panel login, and that is where the one rule of this post lives. Drush on a site is the whole database, reading and writing, and a one-time admin login whenever it likes; which is exactly the power the Client role already carries in the panel, with Backup, Export and Reset password, no more and no less. So the engine bay key goes on the ring of a person who holds the Client role, and it never goes beside a Site operator login, since the shell would then return the two things the panel role was cut to keep away; a site operator who has to touch a theme gets the boot key, the files login, and the docs say so on every page where somebody might be tempted otherwise, the operator’s included.
It came out of a real question, the way most of BOA came out of real questions; a hosted customer preparing a security review wanted the part of the team which operates the sites to be unable to take a database home or to log into production as its administrator, with one designated person keeping the full powers, and that is exactly what the Ægir panel of a BOA server says now, with one role. Two more things go with the role, since a role which withholds the Backup button while the Export button on the next tab hands out the archive would be a valet key with the boot left open: the whole Backups tab follows the login’s permissions, Export and Get on a permission of their own, Delete and Restore on the same task permissions the site page checks; and the one-time link which a Reset password task mints sits on the site page as a button for one day, shown to the logins allowed to reset passwords and to nobody else, and never in the task log. A colleague attached to one Client sees that Client’s sites and nothing of another Client’s on the same account, task logs included, and cannot run a task again by typing in its number unless it is one they could have queued themselves, on a site of theirs; and because three people on one account is exactly when you want to know who did what, every task records the login which queued it, Queued by on the task page and a column in the lists, the system where the nightly maintenance or cron queued it, kept as long as the site exists, no request to your host and no log archaeology.
Your own login, by the way, is not “a Client login”, though I have been sloppy about that myself; it carries three roles together, admin, account manager and Client, which is why it is the one which deletes sites, makes platforms, creates Clients and attaches people to them, and sees the People list. The Client role on its own is the spare full key, the one a partner gets: every site task including Backup, Restore, Export and the admin link, on the sites of the Client they are attached to, and not deletion, not platforms, not Clients. Give it to somebody you would hand a database copy to, because that is what it is, and give the valet key to everybody else; either one is cut by your host, who needs the person’s name, the role and the Client to attach them to, and nothing more.
What keeps this honest is how little of it you are asked to take on trust. The roles are a list shipped with BOA, the same on every server, put back the way BOA ships it every night and at every upgrade, so a permission somebody ticks by hand at midnight is gone by morning and there is no such thing as a custom role quietly widened on one box, which is a guarentee I like better than a promise; the only thing your host changes is which role sits on which login, and you can read that, and the Queued by column, and the two shell logins in one file each, without asking anybody. For the platform crowd it is the same seat, except that every role behind it is written down to the permission on a page you can open, and which login holds which role is one line on a server you rent in your own name, changed by somebody you can ask. For the ones who still run their own server it is the end of the second admin account made in a hurry on a Friday, the one which was going to be temporary.
Back to the blog »
Has your team ever kept the control panel password in a chat channel, the one login for everybody, because the panel knew only one kind of user and the alternative was a second admin who could do everything anyway; and then an auditor asked the simple question, who here can download the production database, and the honest answer was, whoever has scrolled up far enough? Or have you picked “Developer” for a new hire from a dropdown of roles somebody else wrote, and found out a month later, by accident, that the seat could pull the database to a laptop all along?
If you ever had a car with a valet key you already know the design. The valet key starts the engine and drives the car, so the valet can park it and bring it round, and it opens neither the glovebox nor the boot, so whatever you keep in there stays yours; and the nice part is that the valet never feels short of a key, because parking is the whole job. The Site operator role is that key, cut for the control panel: it verifies, clones, migrates, flushes caches, runs the database updates, switches a site off and on, edits its settings and its aliases, and it reads every task log of every site of its Client; and it can not back a site up, restore it, export a copy or delete a backup, nor mint the one-time admin login, nor delete the site itself. The Backups tab it does see, the list with the dates and the sizes, only the buttons are not on it, and the links behind them refuse when typed in by hand, because the boundary sits on the server and the missing buttons are a courtesy.
On a BOA server every login is a key of one kind and there are six on the ring, which sounds like a lot until you notice each of them answers a different question. The two you were handed at the start, the panel login and the oN.ftp shell, open everything you own; a colleague’s login to the Ægir panel holds one of two roles, Client, which does with a site whatever you can short of deleting it, backups, exports and the admin login link included, or the new Site operator, which does the daily work and cannot get at a copy of the database, at the admin account or at the delete button by any road; and a colleague’s shell key comes in two flavours, files and themes, or whole codebases, and only the codebase flavour carries Drush, and Drush is the database. The plain-language page for all six, with a matrix, is logins and roles, and the operator’s reference with every permission spelled out and the commands to cut a key is control-panel roles and logins; what follows is why the ring is cut this way, and what a valet key is doing in a hosting panel.
