remove built-in silo, move built-in users to the test suite

The built-in Silo with its built-in users have been useful, but they were always intended as a stepping stone until we had more real facilities. Once we do #2304, I think we'll be able to remove these.

The remaining hard part is probably the test suite. We may want to have it create its own Silo with these same test users. The difference will only be that these are created by the test suite rather than automatically by Nexus. This is kind of a big difference in terms of security, since these test users won't be present in real systems.

Depends on #2304.

The test suite is already using the RSS -> Nexus transfer-of-control request, and as of #2943 that will create the recovery Silo, with an initial privileged user, so that part should be pretty smooth.

@luqmana

After talking with @luqmana, it seems useful to keep a built-in Silo as a container for the system's own resources (e.g., VPC or Project for Nexus and other Omicron stuff). At this point it still seems like one you shouldn't be able to log into. We definitely want to remove the built-in users that are currently only there for the test suite and demos. This is blocked on oxidecomputer/console#1457 (to avoid breaking everybody's workflows).

I’m going to work on that today.

Currently, we have these built-in silo and user records:

root@[fd00:1122:3344:101::3]:32221/omicron> select * from silo where time_deleted is NULL;
                   id                  |      name       |              description              |         time_created          |         time_modified         | time_deleted | discoverable | authentication_mode | user_provision_type |  mapped_fleet_roles   | rcgen
---------------------------------------+-----------------+---------------------------------------+-------------------------------+-------------------------------+--------------+--------------+---------------------+---------------------+-----------------------+--------
  001de000-5110-4000-8000-000000000000 | default-silo    | default silo                          | 2023-08-01 16:58:15.445979+00 | 2023-08-01 16:58:15.445979+00 | NULL         |    false     | local               | api_only            | {}                    |     1
  001de000-5110-4000-8000-000000000001 | oxide-internal  | Built-in internal Silo.               | 2023-08-01 16:58:15.445996+00 | 2023-08-01 16:58:15.445996+00 | NULL         |    false     | local               | api_only            | {}                    |     2
  2575401e-7207-4df0-b6b3-ad61b153ff8a | recovery        | built-in recovery Silo                | 2023-08-01 16:59:45.121648+00 | 2023-08-01 16:59:45.121648+00 | NULL         |    false     | local               | api_only            | {"admin": ["admin"]}  |     2
(3 rows)


Time: 9ms total (execution 8ms / network 1ms)

root@[fd00:1122:3344:101::3]:32221/omicron> select * from user_builtin;
                   id                  |       name       |                     description                     |         time_created          |         time_modified         | time_deleted
---------------------------------------+------------------+-----------------------------------------------------+-------------------------------+-------------------------------+---------------
  001de000-05e4-4000-8000-000000000001 | db-init          | user used for database initialization               | 2023-08-01 16:57:32.199623+00 | 2023-08-01 16:57:32.199623+00 | NULL
  001de000-05e4-4000-8000-000000000002 | internal-api     | used by Nexus when handling internal API requests   | 2023-08-01 16:58:15.267206+00 | 2023-08-01 16:58:15.267206+00 | NULL
  001de000-05e4-4000-8000-000000000003 | external-authn   | used by Nexus when authenticating external requests | 2023-08-01 16:58:15.267207+00 | 2023-08-01 16:58:15.267207+00 | NULL
  001de000-05e4-4000-8000-000000003a8a | saga-recovery    | used by Nexus when recovering sagas                 | 2023-08-01 16:58:15.267207+00 | 2023-08-01 16:58:15.267207+00 | NULL
  001de000-05e4-4000-8000-000000004ead | internal-read    | used by Nexus to read privileged control plane data | 2023-08-01 16:58:15.267207+00 | 2023-08-01 16:58:15.267207+00 | NULL
  001de000-05e4-4000-8000-00000000bac3 | service-balancer | used for Nexus-driven service balancing             | 2023-08-01 16:58:15.267205+00 | 2023-08-01 16:58:15.267205+00 | NULL
(6 rows)

root@[fd00:1122:3344:101::3]:32221/omicron> select * from silo_user where silo_id in ('001de000-5110-4000-8000-000000000000', '001de000-5110-4000-8000-000000000001');
                   id                  |         time_created          |         time_modified         | time_deleted |               silo_id                | external_id
---------------------------------------+-------------------------------+-------------------------------+--------------+--------------------------------------+---------------
  001de000-05e4-4000-8000-000000004007 | 2023-08-01 16:58:16.008882+00 | 2023-08-01 16:58:16.008882+00 | NULL         | 001de000-5110-4000-8000-000000000000 | privileged
  001de000-05e4-4000-8000-000000060001 | 2023-08-01 16:58:16.008883+00 | 2023-08-01 16:58:16.008883+00 | NULL         | 001de000-5110-4000-8000-000000000000 | unprivileged
(2 rows)

IIUC, the silo and users to be removed are default-silo, the privileged and unprivileged users (btw, the two users do not have a password record and can't log into the system so there is no security risk and the urgency for this change is relatively low -- but the change now has to be done through the db schema migration).

Yes, all of that matches my understanding. The lack of risk is why I deferred it for FCS. But I'd still like to do it soon to minimize the number of customers on which we have to do it manually via a schema update operation.

One thing to note is that the privileged user's fleet admin role may already be dropped in customer's deployment because they can do PUTs using the /v1/system/policy API. The schema updater script should not bail (i.e. error out, abort prematurely) if it can't find the record in the role_assignment table.

Now that we have an automatic process during upgrades that can modify the database, I think this is even less urgent.

Navigation Menu

Repository navigation

remove built-in silo, move built-in users to the test suite #2305

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

remove built-in silo, move built-in users to the test suite #2305

Description

Activity

davepacheco commented on Apr 27, 2023

davepacheco commented on May 23, 2023

david-crespo commented on May 23, 2023

askfongjojo commented on Aug 21, 2023

davepacheco commented on Aug 21, 2023

askfongjojo commented on Sep 1, 2023

davepacheco commented on Nov 28, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions