Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Field name

Type

Allow nulls

Key

Default value

id

bigint(20) unsigned

No

Primary

Null

uuid

varchar(40)

Yes

None

Null

name

varchar(255)

Yes

None

Null

url

varchar(255)

No

None

Null

username

varchar(255)

No

None

Null

password

varchar(255)

No

None

Null

data_center_id

bigint(20)

No

None

Null

removed

datatime

Yes

None

Null

Web Services APIs

  1. registerAttestationServer : A new api to register an attestation server with cloudstack. It will take the details of the attestation server as a parameter and check if a connection can be established to it.

    Parameters

    Type

    Required/Optional

    Comments

    url

    String

    Required

    Url of the attestation server

    username

    String

    Required

    Username with which cloudstack should register and connect with the attestation server

    password

    String

    Required

    Password with which cloudstack should register and connect with the attestation server

    zoneid

    UUID

    Required

    Zone to which the attestation server will be registered with

    name

    String

    Optional

    Friendly name the identify the attestation server


    Response Object

    Comment

    AttestationServerResponse

    The parameters contained in the response object are uuid, url and username

  2. listAttestationServer : A new api to list the attestation server registered with cloudstack. It will return AttestationServerResponse in response.

    Parameters

    Type

    Required/Optional

    Comments

    id

    UUID

    Optional

    Attestaion server id

  3. unregisterAttestationServer : A new api to unregister an attestation server. It will return SuccessResponse.

    Parameters

    Type

    Required/Optional

    Comments

    id

    Uuid

    Required

    Id of the attestation server

  4. registerHostWithAttestaionServer : A new api to register a host with the attestation server. It will whitelist and register the host with the attestation server. It will return RegisterHostWithAttestaionServerResponse object.

    Parameters

    Type

    Required/Optional

    Comments

    id

    Uuid

    Required

    Id of the host. This host gets whitelisted and registered with the attestation server registered for the zone to which the host belongs


    Response Object

    Comment

    RegisterHostWithAttestaionServerResponse

    The parameters contained in the response object are id of the host, attestation server id and flags detailing whether whitelisting, registeration and trust assertion of the host were successful.

Test Guidelines

<TBD>

Hypervisor support

...

All successful operations are logged to INFO, all exceptions/failures to ERROR, and all synchronization checks to DEBUG.

Events/Alerts

If an instance created from a service offering requires a trusted host and it is placed on an untrusted or unattested host, an alert will be raised to bring it to administrators attention.

UI Flow

...

Open Issues

...

The feature will be accessible only through apis. Whether a host is trusted or not can be established by looking at its tags.

Open Issues

  1. Should the
  2. and on getting a host not registered exception, register it? Or instead, keep the information on whether a host is registered or not in the db.
  3. Proposal is to fill the host_details table with an additional attribute for an host on checking if it is trusted or not. Should this information be stored elsewhere, probably in a separate table?
  4. For Anti-affinity and Dedicated resources features changes are being made to address how an instance is deployed. It'll also affect this feature. For the current feature, changes are needed in the host allocators to not to pick up an untrusted host if the service offering requires trusted host. How should a service offering be updated to include the information that a trusted host is required? Should it be done using name/value pairs, as has been suggested for Dedicated resource feature. However, name/value pairs will be the property of a planner (I could be wrong); and here we need to pass this information to the allocators.
  5. Should the attestation server details be kept in a new table or can they be kept in the <db>.host table itself? Proposal: A new table to keep the attestation server details.