Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Define security of iaas service software #749

Open
5 tasks
josephineSei opened this issue Sep 16, 2024 · 1 comment · May be fixed by #765
Open
5 tasks

Define security of iaas service software #749

josephineSei opened this issue Sep 16, 2024 · 1 comment · May be fixed by #765
Assignees
@josephineSei
Labels
IaaS Issues or pull requests relevant for Team1: IaaS SCS is standardized SCS is standardized SCS-VP10 Related to tender lot SCS-VP10 standards Issues / ADR / pull requests relevant for standardization & certification

Comments

@josephineSei
Copy link
Contributor

In SovereignCloudStack/issues#528 we define sets of mandatory and supported APIs.
This is a lengthy discussion.

But we may not only define, what APIs we expect to see in a cloud but also how old they are allowed to be.
On the KaaS Layer there is already a standard: https://github.com/SovereignCloudStack/standards/blob/main/Standards/scs-0210-v1-k8s-new-version-policy.md , which advises to closely follow the K8s releases.

We need to also define a period of Liveness for the IaaS Layer.

Definition of Done:

Please refer to scs-0001-v1 for details.

  • Proposal has been written with name of the form scs-xxxx-v1-slug.md (only substitute slug)
  • Proposal has the fields status, type, track set
  • Proposal has been voted upon in the corresponding team
  • Status has been changed into Draft, file renamed: xxxx replaced by document number
  • If applicable: test script has been written (this item may be moved into a separate issue so long as the state is Draft)
@josephineSei josephineSei self-assigned this Sep 16, 2024
@josephineSei josephineSei added IaaS Issues or pull requests relevant for Team1: IaaS SCS-VP10 Related to tender lot SCS-VP10 standards Issues / ADR / pull requests relevant for standardization & certification SCS is standardized SCS is standardized labels Sep 25, 2024
@josephineSei josephineSei moved this from Backlog to Doing in Sovereign Cloud Stack Sep 25, 2024
@josephineSei
Copy link
Contributor Author

The question here is: How can we determine, which version of the IaaS-API is used? And how many version we want to support on IaaS-Level.

  1. One Option would be to allow all IaaS APIs, that are still maintained (e.g. OpenStack services, that are still maintained and not in EOL or Unmaintained: https://releases.openstack.org/).
  2. Another Option would be to also allow Unmaintained release, when CSPs will A) fix all security issues themself and B) maybe have an upgrade plan to finally rely on maintained IaaS services.

Testing this will be quite tricky.

We could use the openstack version show:

stack@devstack:~/devstack$ openstack versions show
+-------------+----------------+---------+-----------+---------------------------------------------+------------------+------------------+
| Region Name | Service Type   | Version | Status    | Endpoint                                    | Min Microversion | Max Microversion |
+-------------+----------------+---------+-----------+---------------------------------------------+------------------+------------------+
| RegionOne   | placement      | 1.0     | CURRENT   | http://192.168.23.161/placement/            | 1.0              | 1.39             |
| RegionOne   | compute        | 2.0     | SUPPORTED | http://192.168.23.161/compute/v2/           | None             | None             |
| RegionOne   | compute        | 2.1     | CURRENT   | http://192.168.23.161/compute/v2.1/         | 2.1              | 2.96             |
| RegionOne   | block-storage  | 3.0     | CURRENT   | http://192.168.23.161/volume/v3/            | 3.0              | 3.71             |
| RegionOne   | image          | 2.0     | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.1     | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.2     | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.3     | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.4     | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.5     | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.6     | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.7     | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.9     | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.14    | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.15    | SUPPORTED | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | image          | 2.16    | CURRENT   | http://192.168.23.161/image/v2/             | None             | None             |
| RegionOne   | compute_legacy | 2.0     | SUPPORTED | http://192.168.23.161/compute/v2/           | None             | None             |
| RegionOne   | compute_legacy | 2.1     | CURRENT   | http://192.168.23.161/compute/v2.1/         | 2.1              | 2.96             |
| RegionOne   | key-manager    | 1.0     | CURRENT   | http://192.168.23.161/key-manager/v1/       | None             | None             |
| RegionOne   | identity       | 3.14    | CURRENT   | http://192.168.23.161/identity/v3/          | None             | None             |
| RegionOne   | network        | 2.0     | CURRENT   | http://192.168.23.161:9696/networking/v2.0/ | None             | None             |
+-------------+----------------+---------+-----------+---------------------------------------------+------------------+------------------+

But within there we only have the microversions, which not all projects have and which may not be updated in certain releases. (+ the key-manager uses microversions, but it is not shown here!)
That means we can only sporadically test certain API endpoints - and for non-OpenStack use cases, the micro-versions might even differ.

Another Option would be to specifically test for certain endpoints to be present (e.g. openstack default security group rule list) . This would include non-OpenStack services, but is so specific, that we may have to update this test every release cycle.

@josephineSei josephineSei linked a pull request Sep 30, 2024 that will close this issue
Open
@josephineSei josephineSei changed the title Define minimum requirement of IaaS APIs Define security of iaas service software Oct 4, 2024
This was referenced Oct 28, 2024
Open
Open
Open
@josephineSei josephineSei mentioned this issue Nov 8, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@josephineSei josephineSei

Labels
IaaS Issues or pull requests relevant for Team1: IaaS SCS is standardized SCS is standardized SCS-VP10 Related to tender lot SCS-VP10 standards Issues / ADR / pull requests relevant for standardization & certification
Projects
Sovereign Cloud Stack
Status: Doing
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Create a standard for the security of iaas service software SovereignCloudStack/standards
1 participant
@josephineSei