[EPIC] IaaS standards - Githubissues

mbuechse commented 1 year ago

General

Standard for Standards & Documentation

Mandatory Openstack Services

[ ] https://github.com/SovereignCloudStack/issues/issues/528

Computing

Flavor naming, flavor selection, and flavor discoverability:

Standard flavors

[x] https://github.com/SovereignCloudStack/standards/issues/504

OpenStack powered Compute 2022.11

https://opendev.org/openinfra/interop/src/branch/master/guidelines/2022.11.json
Refstack in Ref.Impl. but not generic
[ ] #300

Storage

Volume types

[ ] https://github.com/SovereignCloudStack/standards/issues/468

Network

public network

[ ] https://github.com/SovereignCloudStack/issues/issues/167
[ ] IPv6 networking is implemented, documented but not standardized (https://github.com/SovereignCloudStack/issues/issues/166)

Network Time Protocoll

[ ] https://github.com/SovereignCloudStack/issues/issues/231

DNS

L3 loadbalancer (OVN)

Needed for good support of externalTrafficPolicy: Local
[x] https://github.com/SovereignCloudStack/issues/issues/251
[x] https://github.com/SovereignCloudStack/issues/issues/268
[ ] What would CSPs and Users would want to have standardized here?

Neutron Policy Standard

[ ] https://github.com/SovereignCloudStack/standards/issues/543

Images

Image Meta Data

Standard Images

Identity

Domain admin role: Allow project creation, user management as self-service (resellers)

[ ] https://github.com/SovereignCloudStack/issues/issues/184

Identity federation via OIDC: Federate users from federated clouds

Security

Baseline security

Database(s)

regulation regarding OpenStack database(s)
[ ] https://github.com/SovereignCloudStack/standards/issues/547

Entropy in VMs

Key Store

[ ] https://github.com/SovereignCloudStack/standards/issues/509

Encryption

[ ] https://github.com/SovereignCloudStack/standards/issues/560

Security Groups

Backup and Redundancy

Taxonomy of Backups

[ ] #527

User Backup

[x] #541

Definition of Availability Zones: Availability expectations when spreading over AZs

Idea: Meaningful level of independence (power, net, fire, cooling, …)
https://github.com/SovereignCloudStack/standards/blob/main/Drafts/SCS-Spec.md#availability-zones
[ ] https://github.com/SovereignCloudStack/standards/issues/539

Definition of Region: What is shared?

Idea: Share identities, replicate images

Unsorted/unclassified

Metadata source (w/ user-data, vendor-data)

Required for customization of VMs

fkr commented 7 months ago

Discussion on how to best proceed with these standards / item that could be standardized in todays meeting with @josephineSei , @markus-hentsch and @mbuechse

We agreed to

0) Follow-up on the flavor/properties/traits discussion that happened as part of the Caracal vPTG - this topic is with @fkr 1a) Work on the topics of DNS and NTP standards, this will be started in the next weeks in Team IaaS 1b) Find out which items / features / functionality should be standardized for the loadbalancing

josephineSei commented 4 months ago

Somehow editing the description of this issue does not show me the correct version. So maybe one of you can include this: Standardized list of OpenStack services: https://github.com/SovereignCloudStack/standards/issues/469

josephineSei commented 4 months ago

I opened an issue for the Security Groups: https://github.com/SovereignCloudStack/standards/issues/473 .

markus-hentsch commented 3 months ago

I discussed with @josephineSei which topics might not be covered yet by SCS standardization appropriately yet and what kind of potential might exist regarding those.

Key rotation

We thought about the possibility of creating a standard or guide for cryptographic key rotation in SCS and had a look at involved components. We deemed the following topics relevant for key rotation.

Cinder Volumes:

encryption uses Barbican keys, no rotation currently supported
key rotation would require a new feature contribution to upstream
rotation could work generating new secret in Barbican and swapping keys in the LUKS key slots
- swapping key in LUKS slot is quick and atomic operation
however, simply swapping keys in the LUKS slots is weak since copies of the old LUKS header (just 2MB) and the old secret can still unlock the current LUKS master key even if the key slot was replaced!
- the effort of implementing this upstream would not be justified by the relatively low security gain
alternative would be to offer online reencryption using LUKS v2^1
- would not be an atomic operation anymore, can become error prone in a lot of ways
- needs complex handling of the progress and state of the potentially lengthy reencryption process

Ephemeral Storage (Nova):

encryption uses Barbican keys, no rotation currently supported
key rotation would require a new feature contribution to upstream
only LVM backend currently suppports encryption^2
more generic support is still WIP^3 and not finished upstream
uses the same LUKS encryption as Cinder volumes, hence the same cryptographic limitations apply, see the Cinder section above

Images (Glance):

image encryption upstream contribution still WIP currently^4
encryption uses Barbican keys, no rotation currently supported
encryption is not LUKS-based, key rotation could only work by reencrypting the full image file
- could be done manually using API or client by downloading, reencrypting and reuploading the image
- upstream implementation in Glance would be costly both in terms of required processing time and disk space

Keystone token provider:

the default backend (Fernet) has a well-known rotation implementation using secondary and staged keys, the keystone-manage utility provides a rotation mechanism^5
upstream documentation could be referenced but is pretty sparse regarding the specific workflow of rotating and distributing the keys correctly
SCS could document a better guide
JWS rotation is easy, they're just individual keypairs per Keystone instance and well documented^6

PKI / TLS

for all API interfaces and backend channels (e.g. RabbitMQ, DB) that can be protected by TLS, a key rotation and certificate exchange can be established
this is usually part of the PKI and seems out of scope for a key rotation standard or guide

Summary: LUKS encryption key rotation (concerns Nova and Cinder) would require an upstream contribution and would either be weak cryptographically (when changing only key slots) or require a lot of effort to get right (online reencryption). Glance image key rotation could be established using guidelines and a manual process but the implementation is not ready yet. The only thing immediately actionable here would be creating a better guide for Keystone Fernet key rotation.

Backups

We briefly discussed the potential necessity of some form of backup guide for user data due to the following considerations:

from a user's POV the backup mechanisms offered by OpenStack might be either insufficient or lacking in terms of clear and concise documentation
Glance images can be downloaded
Cinder volumes
- there's openstack volume backup create but that requires Swift (who uses Swift?)
- openstack server image create when used on a volume-based server will create volume snapshots but snapshots aren't genuine backups! (misleading?)
- alternative: image from volume using imtermediate snapshots, known approach but poorly documented
for Ephemeral Storage there's also openstack server image create which creates Glance images as backup

... so the state seems pretty messy. server image create does different things in a non-obvious way depending on whether Ephemeral Storage or volumes are used. volume backup create does not create genuine backups strictly speaking.

We see potential here to at least formulate a guide to better assist users seeking to implement a backup concept.

josephineSei commented 3 months ago

@markus-hentsch and I further discussed the possible need to:

standardize the usage of TLS and traffic encryption between the OpenStack services and the database at least.
deep-dive into the possibilty to create VPNaaS in Neutron (https://docs.openstack.org/neutron-vpnaas/latest/) and whether this would be needed as a standard.
deep dive into possibilities to isolate a Compute Host for a project, check if that would be a requirement for certain users and possibly make this feature better usable upstream

SovereignCloudStack / standards

[EPIC] IaaS standards #285