Upon completing the Initial Rack Setup steps, the control plane services, including the web console, should be up and running.
In this final part of rack setup, you will configure the external IP addresses to be used by instances, create a new silo, and set up someone as the silo administrator with or without an identity provider (IdP).
Prerequisites
Before proceeding, ensure you have determined which external IP address range(s) can be allocated to virtual machine instances. "External" in this context means addresses reachable outside of the Oxide rack, they do not have to be public IP addresses.
If you plan to use a SAML identity provider (IdP) with this silo, please also review some of the setup examples below for an overview of the IdP integration and the necessary preparations:
The instructions shown in this guide use the Oxide Console. If you prefer to perform the same steps with Oxide CLI or you intend to create local user accounts on Oxide instead of using an IdP, please download the appropriate binaries from https://github.com/oxidecomputer/oxide.rs/releases.
Log into Web Console
In your web browser, log into the Oxide Console with the username recovery at https://recovery.sys.$oxideDomainName and the password specified during the initial rack setup process.
The silo in use here is meant for first-time setup and recovery purposes. In the steps below, we’ll create another silo and grant its administrators fleet access so that these users can manage system-level configurations without logging in as the recovery user again.
Create Device Token (required for CLI only)
Follow the instructions in the CLI and SDKs guide to create a device token. This token is linked to the recovery user and should only be used for managing rack setup.
Create Silo
First, navigate to the System menu using the dropdown at the top right-hand corner of the web console (next to user name). On the Silos menu, click New Silo.
The following information is required when creating a silo:
| attribute | value | ||||||||
|---|---|---|---|---|---|---|---|---|---|
name | Must start with a letter and contain only lower-case letters, numbers, and dashes. | ||||||||
description | A brief description of the silo | ||||||||
discoverable | Whether the silo should be included in silo listing queries (non-discoverable silos are accessible only by direct name or id reference). | ||||||||
identity_mode | There are two options
| ||||||||
admin_group_name | Required if using | ||||||||
mapped_fleet_roles | Optional mappings of fleet-level roles conferred by silo roles, applicable to the | ||||||||
quotas | Compute and storage resource limits.
| ||||||||
tls_certificates | Initial TLS certificates to be used for the new Silo’s console and API endpoints; should be valid for the Silo’s DNS name which follows the convention
|
Follow the create silo instructions in one of the integration examples that matches more closely to the SAML provider you have:
Create silo using the CLI
oxide silo create --json-body silo.json
Here are some examples of the silo.json request payload based on its identity_mode
# identity_mode = saml_jit
# the mapped_fleet_roles enables silo admin group members to act as fleet admin
{
"name": "$siloName",
"description": "$siloDescription",
"discoverable": true,
"identity_mode": "saml_jit",
"admin_group_name": "$idpAdminGroup",
"mapped_fleet_roles": {
"admin": [
"admin"
]
},
"quotas": {
"cpus": 18,
"memory": 8589934592,
"storage": 107374182400
},
"tls_certificates": [{
"name": "initial-install-cert",
"description": "wildcard certificate",
"service": "external_api",
"cert": "$fullCertChainPemBlob",
"key": "$privateKeyPemBlob"
}]
}# identity_mode = local_user
{
"name": "$siloName",
"description": "$siloDescription",
"discoverable": true,
"identity_mode": "local_only",
"quotas": {
"cpus": 18,
"memory": 8589934592,
"storage": 107374182400
},
"tls_certificates": [{
"name": "initial-install-cert",
"description": "wildcard certificate",
"service": "external_api",
"cert": "$fullCertChainPemBlob",
"key": "$privateKeyPemBlob"
}]
}Configure Silo Identity Provider
Perform this step if your silo uses saml_jit for authentication.
The following attributes are required when configuring an identity provider:
| attribute | value | ||||||
|---|---|---|---|---|---|---|---|
name | A short name of the silo’s IdP SAML configuration (the name will be used in the login URL path, see the example under ACL URL). For ease of tracking, this can be set to the same value as the application or service provider identifier in the IdP, but it is not required. | ||||||
description | A brief description of the SAML configuration in the identity provider. | ||||||
idp_metadata_source | Base64 encoded XML of identity provider SAML descriptor; the source can be specified as XML data or a URL for retrieving the metadata. If the URL is used, the rack service must have anonymous access to the endpoint.
| ||||||
idp_entity_id | IdP SAML issuer ID or client root URL. Examples: | ||||||
sp_client_id | The IdP ID that uniquely identifies the Oxide client; it may be labeled as service provider, application, audience, and so on. | ||||||
acs_url | The Oxide Console login endpoint registered with the identity provider for responses and assertions. It follows the naming convention https://$siloName.sys.$oxideDomainName/login/$siloName/saml/$providerName.
For example, if the silo name is
| ||||||
slo_url | Single logout endpoint, may be set to the same value as ACS URL (i.e., taking users back to the Oxide Console login page). | ||||||
technical_contact_email | Email address of identity provider support contact (Note: Oxide rack does not generate email notifications at this time). | ||||||
signing_keypair | (Optional) Used by the client for signing the login request, in the form of base64-encoded DER files.
| ||||||
group_attribute_name | The custom attribute in the SAML access token response that represents the user’s group memberships. The information will be used to create user groups and assign the user to them. |
To set up an identity provider for the new silo, click New Provider on the Identity Providers tab.
You can reference the create identity provider instructions in the integration example you followed earlier that resembles the SAML provider you use.
Create identity provider using the CLI
Execute one of the following commands depending on how you want to specify the IdP metadata
oxide silo idp saml create --silo $siloName --json-body idp.json --metadata-value $base64EncodedMetadataXml
or
oxide silo idp saml create --silo $siloName --json-body idp.json --metadata-url $idpMetadataUrl
Here is a sample request payload of the idp.json file for a silo named "corp" on the delegated domain "oxide.acme.com" with a Google SAML provider.
{
"name": "google",
"description": "Corporate silo google SAML provider",
"idp_entity_id": "https://accounts.google.com/o/saml2?idpid=D12wdrk34",
"sp_client_id": "corp",
"idp_metadata_source": {
"type": "base64_encoded_xml",
"data": ""
},
"acs_url": "https://corp.sys.oxide.acme.com/login/corp/saml/google",
"slo_url": "https://corp.sys.oxide.acme.com/login/corp/saml/google",
"technical_contact_email": "infra@acme.com",
"signing_keypair": {
"public_cert": "$base64EncodedDer",
"private_key": "$base64EncodedDer"
},
"group_attribute_name": "admins"
}recovery silo to delete the silo and recreate it with the correct configuration.Create Local Users
This step is required only for silos that use local_user for authentication.
To create the first user in the silo and grant this user administrator access, you’ll need to execute the following Oxide CLI commands:
# create user oxide silo idp local user create --silo $siloName --json-body user.json # grant silo admin role oxide silo policy update --silo $siloName --json-body policy.json # grant fleet admin role oxide system policy update --json-body policy.json
The user.json and policy.json payloads should look like this
# user.json
{
"external_id": "$loginname",
"password": {
"mode": "password",
"value": "$passwordValue"
}
}# policy.json
{
"role_assignments": [{
"identity_id": "$idReturnedFromCreateUser",
"identity_type": "silo_user",
"role_name": "admin"
}]
}Test User Login
On a separate browser tab or window, log into the newly created silo at https://$siloName.sys.$oxideDomainName, either as yourself via the identity provider or as the local administrator using password authentication.
In the case of IdP integration, if the admin group attributes are configured correctly, your account should be imported into the rack with the silo “admin” role automatically granted. You can confirm your group assignments in the Profile page under Settings.
admin_group_name of the silo.Set silo resource quotas
Virtual compute and storage resources such as vCPUs are shared among users of different silos. For this first silo setup, you can configure the limits to what is required for initial usage and modify them later as needed.
Setting silo quotas using the CLI
oxide silo quotas update \ --silo $siloName \ --cpus $vcpuCount \ --memory $memoryBytes \ --storage $storageBytes
Create and configure IP Pool
IP pools are groups of addresses used for managing instance external IP address allocation. Each silo may have one or more IP pools associated with it, with one designated as the default pool. When an ephemeral or floating IP is provisioned, an address will be automatically assigned from the IP pool specified in the request, or the default pool if it is unspecified.
Follow these steps to create your first IP pool and link it to the new silo:
Locate the IP Pools menu under System, click New IP Pool.
Add one or more IP ranges to this new IP pool. The IP ranges can be discrete start/end IP addresses and do not need to be CIDR blocks.
Navigate back to Silos and click on the name of the silo created earlier.
On the IP Pools tab, click Link Pool and add the IP pool created above.
Click the three dots in the right-most column of the IP pool table and select Make default.
Create IP pool using the CLI
# create the IP pool oxide ip-pool create --name $poolName --description $poolDescription # insert an address range into the new IP pool oxide ip-pool range add --pool $poolName --first $firstIpInRange --last $lastIpInRange # link the pool to your new silo and make it the default oxide ip-pool silo link --pool $poolName --silo $siloName --is-default true
Additional context and considerations about IP pools can be found in the Network Preparations and IP Pools guides.