-
Notifications
You must be signed in to change notification settings - Fork 261
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
proposals: new API for managed Security Groups
- Loading branch information
Showing
1 changed file
with
169 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,169 @@ | ||
| --- | ||
| title: Flexible API for Managed Security Groups | ||
| authors: | ||
| - "@emilienm" | ||
| reviewers: | ||
| - "@jichenjc" | ||
| - "@mdbooth" | ||
| creation-date: 2023-11-22 | ||
| last-updated: 2023-11-22 | ||
|
|
||
| status: provisional | ||
| --- | ||
|
|
||
| ## Title | ||
|
|
||
| Flexible API for Managed Security Groups | ||
|
|
||
| ## Table of Contents | ||
|
|
||
| - [New API for managing Security Groups](#title) | ||
| - [Table of Contents](#table-of-contents) | ||
| - [Glossary](#glossary) | ||
| - [Summary](#summary) | ||
| - [Motivation](#motivation) | ||
| - [Goals](#goals) | ||
| - [Non-Goals/Future Work](#non-goalsfuture-work) | ||
| - [Proposal](#proposal) | ||
| - [User Stories](#user-stories) | ||
| - [Implementation Details/Notes/Constraints](#implementation-detailsnotesconstraints) | ||
| - [Risks and Mitigations](#risks-and-mitigations) | ||
| - [Alternatives](#alternatives) | ||
| - [Upgrade Strategy](#upgrade-strategy) | ||
| - [Additional Details](#additional-details) | ||
| - [Test Plan [optional]](#test-plan-optional) | ||
| - [Graduation Criteria [optional]](#graduation-criteria-optional) | ||
| - [Version Skew Strategy [optional]](#version-skew-strategy-optional) | ||
| - [Implementation History](#implementation-history) | ||
|
|
||
| ## Glossary | ||
|
|
||
| Security Group - A security group is a named set of rules that control traffic to and from virtual machine instances. The rules can specify which ports and protocols to allow, and which IP address ranges to allow traffic to or from. Security groups can be associated with multiple instances, and multiple security groups can be associated with a single instance. Security groups act as a firewall for associated instances, controlling both inbound and outbound traffic at the instance level. | ||
|
|
||
| ## Summary | ||
|
|
||
| This proposal introduces a new API to manage OpenStack Security Groups in a flexible way that will replace some legacy rules that are currently managed by CAPO. | ||
|
|
||
| ## Motivation | ||
|
|
||
| We want users to be able to manage their security groups in a flexible way for both the Control Plane and the Worker Nodes without enforcing unnecessary rules that are not needed by the user. | ||
|
|
||
| ### Goals | ||
|
|
||
| 1. Make the feature configurable via a new API | ||
| 2. Avoid causing and breaking changes to previous users | ||
| 3. Successfully be able to create and manage security groups for both the Control Plane and the Worker Nodes | ||
| 4. Provide a migration path for users who are currently using the legacy rules provided by `OpenStackCluster.spec.managedSecurityGroups` | ||
| 5. Deprecate `OpenStackCluster.spec.apiServerLoadBalancer.additionalPorts` as we'll have an API to create Control Plane Security Group rules (with more flexibility than we have now). Conversion will happen between this parameter and the one for Control Plane Security Group rules, in order to maintain backward compatibility | ||
|
|
||
| ### Non-Goals/Future Work | ||
|
|
||
| 1. Adding a new Controller to manage the Security Groups resources since we haven't defined yet a common way to handle new API objects in CAPO and we don't necessarily need a new controller for this feature now, as we can reuse the existing OpenStackCluster controller | ||
| 2. Removing pre-existing security groups support in OpenStackMachineTemplate, via OpenStackMachineSpec and for the Bastion in OpenStackCluster | ||
| 3. Deprecate `OpenStackCluster.spec.allowAllInClusterTraffic`, otherwise upgrade path becomes complicated. It wouldn't be complex for ingress/egress traffic to be allowed within the cluster through additional rules in the managed Control Plane & Worker security groups. | ||
|
|
||
| ## Proposal | ||
|
|
||
| ### User Stories | ||
|
|
||
| #### As an operator, I want to be able to have more control over my security groups for my Control Plane and Worker Nodes | ||
|
|
||
| As a cluster operator I want to have more control over my security groups for my Control Plane and Worker Nodes. I want to be able to specify the rules I want to have for my Control Plane and Worker Nodes and not have to rely on the default rules that are currently enforced by CAPO. This will allow me to have more control over my security groups and not have to worry about rules that are not needed by my cluster. | ||
|
|
||
| ### Implementation Details/Notes/Constraints | ||
|
|
||
| The plan is to modify the existing Controllers that already handle opinionated Security Groups when the `managedSecurityGroups` is set to `True`. Until we have the need to create a new Controller, we'll use the existing ones. | ||
|
|
||
| An operator will be able to decide how to manage the Security Groups for the Control Plane and Worker Nodes by using a new API. This new API will be used to create the Security Groups and the rules that are needed for the Control Plane and Worker Nodes. | ||
|
|
||
| #### Data model changes | ||
|
|
||
| `OpenStackCluster` will be changed and the proposed changes are purely additive and nonbreaking. No removals should be required to the data model. For `OpenStackCluster` we will add a new optional field in `spec.SecurityGroupsSpec` and then under it we'll have both `ControlPlaneSecurityGroupRules` and `WorkerSecurityGroupRules` which will represent the Security Groups for the Control Plane and Worker Nodes respectively. | ||
|
|
||
| Example `OpenStackCluster` yaml: | ||
|
|
||
| ```yaml | ||
| apiVersion: infrastructure.cluster.x-k8s.io/v1beta1 | ||
| kind: OpenStackCluster | ||
| metadata: | ||
| name: cluster-sample | ||
| namespace: default | ||
| spec: | ||
| securityGroupsSpec: | ||
| controlPlaneSecurityGroupRules: | ||
| - direction: ingress | ||
| ethertype: IPv4 | ||
| portRangeMin: 22 | ||
| portRangeMax: 22 | ||
| protocol: tcp | ||
| - direction: ingress | ||
| ethertype: IPv4 | ||
| portRangeMin: 6443 | ||
| portRangeMax: 6443 | ||
| protocol: tcp | ||
| - direction: ingress | ||
| ethertype: IPv4 | ||
| portRangeMin: 2379 | ||
| portRangeMax: 2380 | ||
| protocol: tcp | ||
| - direction: ingress | ||
| ethertype: IPv4 | ||
| portRangeMin: 10250 | ||
| portRangeMax: 10250 | ||
| protocol: tcp | ||
| workerSecurityGroupRules: | ||
| - direction: ingress | ||
| ethertype: IPv4 | ||
| portRangeMin: 22 | ||
| portRangeMax: 22 | ||
| protocol: tcp | ||
| - direction: ingress | ||
| ethertype: IPv4 | ||
| portRangeMin: 10250 | ||
| portRangeMax: 10250 | ||
| protocol: tcp | ||
| - direction: ingress | ||
| ethertype: IPv4 | ||
| portRangeMin: 80 | ||
| portRangeMax: 80 | ||
| protocol: tcp | ||
| - direction: ingress | ||
| ethertype: IPv4 | ||
| portRangeMin: 443 | ||
| portRangeMax: 443 | ||
| protocol: tcp | ||
| ``` | ||
| We will replace the `managedSecurityGroups` field with `managedLegacySecurityGroups` which will be a boolean and will be used to determine if the legacy rules should be managed or not. This will be used to provide a migration path for users who were using the legacy rules provided by `OpenStackCluster.spec.managedSecurityGroups`. We'll add conversion logic to convert the old `managedSecurityGroups` field to the new `managedLegacySecurityGroups` field. | ||
|
|
||
| Legacy rules and new rules will be managed in parallel, until we decide to remove the legacy rules. Which means that they can be used together, as they'll live in their own Security Groups. | ||
|
|
||
| ### Risks and Mitigations | ||
|
|
||
| Example risks: | ||
|
|
||
| WIP | ||
|
|
||
| ## Alternatives | ||
|
|
||
| No currently known alternatives exist which are public and have been implemented for CAPO. | ||
| Another option would be to extend what was done in `managedSecurityGroups` by adding an option to disable the default rules that are currently enforced by CAPO. This would allow the user to have more control over their security groups and not have to worry about rules that are not needed by their cluster. This would be a good alternative to the current implementation of `managedSecurityGroups` but it would not be as flexible as the proposed solution. | ||
|
|
||
| ## Upgrade Strategy | ||
|
|
||
| WIP | ||
|
|
||
| ## Additional Details | ||
|
|
||
| ### Test Plan | ||
|
|
||
| There will be e2e tests where we handle the creation of the Security Groups and the rules that are needed for the Control Plane and Worker Nodes. We will also test the migration path for users who are currently using the legacy rules provided by `OpenStackCluster.spec.managedSecurityGroups`. | ||
|
|
||
| ### Version Skew Strategy | ||
|
|
||
| The feature itself should not depend significantly on the version of CAPI and will be backwards compatible with old versions of CAPO since it will be adding new options. If there is a drift in CAPI and CAPO versions, the functionality should stay the same without breaking anything. | ||
|
|
||
| ## Implementation History | ||
|
|
||
| - [ ] 11/21/2023: Open WIP PR [ https://github.com/kubernetes-sigs/cluster-api-provider-openstack/pull/1751 ] | ||
| - [ ] 11/22/2023: Open this KEP PR |