Service endpoints

Objective

These are the hosts a customer can actually reach today. The Endpoints and regions convention proposes a <service>.<region>.<domain> shape with the domain marked OPEN (Michael); what is deployed is flatter and the domain is decided. Where the two disagree, this page describes reality and the convention page describes the intent.

One list, three consumers: the deployment registers these hostnames in the identity service catalog, routes them to the services behind them, and declares their DNS.

The hosts

All on shelfcs.com, all HTTPS on 443.

Hostname	Service	the cloud platform project	Local port
identity.shelfcs.com	Identity	the identity service	5000
ec2.shelfcs.com	EC2-compatible API	ec2-api	8788
compute.shelfcs.com	Compute	the compute service	8774
image.shelfcs.com	Images	the image service	9292
network.shelfcs.com	Networking	the networking service	9696
volume.shelfcs.com	Block storage	the block-storage service	8776
placement.shelfcs.com	the placement service	the placement service	8780
rating.shelfcs.com	Rating	the rating service	8889
console.shelfcs.com	Web console	the web console	9999
console-api.shelfcs.com	Web console API	the web console API	9998
vnc.shelfcs.com	Instance console proxy	noVNC	6080

There is no endpoint discovery service. Construct a host from this table, or read the identity service catalog with --os-interface public.

How the traffic reaches us

client → edge (TLS terminates here) → private transport → the service

Every API binds to a private network only; no service port is exposed to the internet directly. Traffic reaches them through a single managed ingress, which means:

• There is no origin address to attack.
• TLS terminates at the edge.
• If the ingress is down, every endpoint is down at once. There is no second path and no failover.

[!warning]

The ingress is not yet doing everything it should. There is no rate limiting configured on it, and none on the authentication endpoint. Until those exist, treat the absence as a gap rather than as permission.

Regions and the credential scope

There is one region, hel1 (Hetzner Helsinki), and one zone, hel1-a.

The region name is not in the hostname, but it is in the SigV4 credential scope. A client must be told hel1 explicitly:

aws --endpoint-url https://ec2.shelfcs.com --region hel1 ec2 describe-instances

provider "aws" {
  region                      = "hel1"
  skip_credentials_validation = true
  skip_requesting_account_id  = true
  skip_metadata_api_check     = true
  endpoints { ec2 = "https://ec2.shelfcs.com" }
}

Get the region wrong and every call returns SignatureDoesNotMatch with nothing in the message that tells you why. That is SigV4’s behaviour, not ours.

hel1 is not an AWS-shaped region name, and anything that regexes AWS region names will not like it — whether to move to eu-north-1 is OPEN (Michael) on the conventions page.

Where the EC2 endpoint differs from the rest

ec2.shelfcs.com is the only host that speaks SigV4 with an access key pair. Signatures are verified by the identity service’s the identity service’s signature-verification call, so an EC2 access key is the identity service credential underneath.

Every other host on the table speaks the identity service tokens — X-Auth-Token, obtained from identity.shelfcs.com. See Account developer guide.

Two credentials, one identity. Revoking the identity service user revokes both.

What is not published

• No object storage. There is no Swift, no S3-compatible endpoint. Anything written for S3 has nothing to talk to here.
• No DNS, no load balancer (Octavia), no managed Kubernetes, no managed database, no queue, no secrets service, no telemetry API.
• No billing. or account. host. The conventions page names both; what exists instead is the storefront Worker — see Account API.
• No status page.

An unpublished service is not a service running behind a firewall waiting to be switched on. It does not exist.

Go further

• Endpoints and regions — the proposed convention
• Authentication
• Account developer guide
• Web console and VNC