Upon completing the Initial Rack Setup steps, the control plane services, including the web console, should be up and running.
In this final step of rack setup, you will configure the external IP addresses to be used by instances, create a user silo, and set up someone as the silo administrator with or without an identity provider (IdP).
1. Prerequisites
Before proceeding, confirm that the necessary networking preparations and identity provider setup have been completed.
The steps below require you to make use of the Oxide CLI. Download the appropriate binary from https://github.com/oxidecomputer/oxide.rs/releases.
2. Login Web Console
Open a session in the default browser of your workstation, log into the Oxide web console as the “recovery” user at https://recovery.sys.$oxideDomainName using the password specified during the initial rack setup process.
3. Create Device Token
Follow the instructions in Working with the API and CLI to create a device token. This token is linked to the recovery user and should only be used for managing rack setup.
4. Create a User 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 | |||||||
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 | If set, this group will be created during Silo creation and granted the "Silo Admin" role, applicable to | ||||||
mapped_fleet_roles | Optional mapping of which Fleet roles are conferred by each Silo role, applicable to | ||||||
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
|
To create a silo, execute
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"
}]
}
5. Configure Silo Identity Provider
Perform this step only if your silo uses saml_jit for authentication.
The following attributes are required when configuring an identity provider:
| attribute | value | ||||||
|---|---|---|---|---|---|---|---|
name | Name of the IdP realm backing the Oxide silo | ||||||
description | IdP service description | ||||||
idp_metadata_source |
| ||||||
idp_entity_id | IdP realm root URL | ||||||
sp_client_id | IdP client or app ID | ||||||
acs_url | Endpoint on the Oxide Console to which the identity provider will redirect with its authentication response | ||||||
slo_url | Single logout endpoint, may be set to the same value as ACS URL (i.e. taking user 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 | Used by the client for signing the login request
| ||||||
group_attribute_name | The custom attribute that captures group name information (in the form of a comma-separated list) that is returned as part of the SAML access token response. The information will be used to auto-create IAM groups and assign the user to those groups. |
To configure the IdP for the silo created above, 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 for the idp.json file
{
"name": "example",
"description": "Oxide Silo SAML IdP",
"idp_entity_id": "https://accounts.google.com/o/saml2?idpid=example123",
"sp_client_id": "example-oxide",
"idp_metadata_source": {
"type": "base64_encoded_xml",
"data": ""
},
"acs_url": "https://$siloName.sys.rack2.eng.oxide.computer/login/$siloName/saml/example",
"slo_url": "https://$siloName.sys.rack2.eng.oxide.computer/login/$siloName/saml/example",
"technical_contact_email": "itadmin@test.com",
"signing_keypair": {
"public_cert": "$base64EncodedDer",
"private_key": "$base64EncodedDer"
}
"group_attribute_name": "admins"
}6. Create Local Users
Perform this step only if your silo uses local_user for authentication.
To create the first user in the silo and grant this user administrator access, execute
# 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
Here is how the user.json and policy.json payloads should look like
# user.json
{
"external_id": "$loginname",
"password": {
"mode": "password",
"value": "$passwordValue"
}
}
# policy.json
{
"role_assignments": [{
"identity_id": "$idReturnedFromCreateUser",
"identity_type": "silo_user",
"role_name": "admin"
}]
}7. 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.8. Create and configure IP Pool
IP pools are logical abstractions for external IP address allocation. Each silo may have one or more IP pools associated with it and must have one of them set as the default. When a VM instance is provisioned, IP addresses will be automatically assigned from the IP pool specified in the request as long as the pool is linked to the silo.
Follow these steps to create your first IP pool and link it to the new silo:
# create the IP pool oxide ip-pool create --pool $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
An IP pool may include one or multiple address ranges and they do not need to be contiguous. The number of IP addresses to allocate to each pool will depend on the expected number of VM instances using it. You can always start with a small IP range and add more address ranges later on.
Additional context and considerations about the data network are available in the Network Preparations and IP Pool Management guides.