See RFD 234 section 1.4 ("Initial setup, special Silos") and RFD 278 determinations. The plan (as I understand it) is that during initial setup on the technician port, the customer will provide (or get from the system) a password. We will use this to create the initial Recovery Silo and an initial user in that Silo using that password. The customer can then log into the Recovery Silo with that user and password and set up another Silo that's hooked up to their identity provider.

I think this work involves:

• The transfer-of-control request needs to accept whatever information is needed to create the initial Silo and Silo User. At minimum I think this would be the new user's password. Nexus can probably figure out the rest. I'm not sure if there's value in allowing the Silo name or user name to be provided in this request. (Even if we decide the customer can't change this, RSS could. Is that useful?)
• All callers of the transfer-of-control request need to be updated:
  • I think the non-simulated Sled Agent currently acts as RSS, using input from this config file? In that case this config file could grow a field for specifying the initial password?
  • The simulated Sled Agent makes this request. It should probably get the password from the user (e.g., a command-line argument or interactive prompt) rather than hardcoding one.
  • The test suite is deliberately as close to the simulated Sled Agent as possible. We should make sure its simulated Sled Agent makes the transfer-of-control request too. It should probably use a hardcoded password that's only in the test suite code (i.e., not compiled into any shipping binaries).

I believe most of that is necessary for MVP anyway. With that done, I think we should be able to remove the built-in Silo and privileged/test-privileged users. I'll file a separate ticket for that.