Skip to content

Latest commit

 

History

History
146 lines (119 loc) · 5.91 KB

27-cloudprofile-bastion-section.md

File metadata and controls

146 lines (119 loc) · 5.91 KB
title gep-number creation-date status authors reviewers
Add Optional Bastion Section To CloudProfile
27
2024-05-08
implementable
@hebelsan
@kon-angelo
@AndreasBurger
@rfranzke
@timuthy

GEP-27: Add Optional Bastion Section to CloudProfile

Table of Contents

Summary

Our plan is to extend the gardener core CloudProfile with a new bastion section that will allow us to create a bastion instance with a specific machine image and machine type that will be referenced in that new section.

Motivation

We are working on updating the bastion images used in our controllers. Some of these machine images were hardcoded in the controller. We were using different image "families" in some providers like Debian, and in others GardenLinux. We had "custom" logic per provider to determine the latest image and so on.

The process of looking for the first "supported" version is something we agree with. However, without such a place for the machine image, we will depend on the implicit order of the MachineImage array. Our plan is to extend the gardener core CloudProfile with a new bastion section that will allow us to create a bastion instance with a specific machine image and machine type that will be referenced in that new section.

There are some advantages to this approach compared to the current one:

  • Consistently use GardenLinux image where possible
  • Easier to maintain
  • Known systemd and ssh requirements for the images

Drawbacks:

  • Bastion is using larger machine types and larger images

The drawback of using larger machine types stems from the requirement to use machine types that meet the minimum specifications for Kubernetes nodes as dictated by Gardener. Meanwhile, providers often offer smaller machines that would be more suitable for use as bastions. This issue could be resolved by utilizing the usable field in the CloudProfile (set to usable: false for shoot workers) to allocate smaller machines for use as bastions.

Goals

  • Unify bastions across all providers
  • Have a clear definition which image and machine type to use for the bastion

Prerequisites

Newer GardenLinux versions have ssh disabled by default. In order for the bastion to work with newer GardenLinux versions we need to update the UserData content that is generated by the gardenlet bastion controller. Since all OSes in the CloudProfile are based on systemd, adding the following line should be enough:

systemctl start ssh

In case the ssh service is already running, this command will have no effect.

Proposal

We propose to add a new bastion section to the CloudProfile which specifies the bastion creation parameters. For the machine image, we want to include a reference to one of the machineImages in the CloudProfile. We can then use the CloudProfile upon request, to deref that image to the provider specific reference. In addition, we want to define a machineType that specifies the bastions VM type. Example:

apiVersion: core.gardener.cloud/v1beta1
kind: CloudProfile
metadata:
  name: cloudprofile1
spec:
  type: aws
  bastion:
    machineImage:
      name: gardenlinux
      version: 1443.3.0
    machineType:
      name: n1-standard-2
...

To be backwards compatible and support CloudProfiles with no bastion section we will use the following fallback strategy:

  • Use the first found supported image
  • Use the first found usable machine type

The disadvantage of the fallback strategy is that you implicitly become dependent on the order and in worst case a machine type that is clearly too large could be used for bastions.

Alternatives

Place Bastion Configuration Somewhere Else

We can argue if that place should be in the CloudProfile. There are other places we could use - like the configuration of the provider-extension. The CloudProfile allows us then to have that extra validation to make sure that the image is there. Specifying the bastion configuration in the CloudProfile though has the benefit of maintaining everything at one point. Otherwise we would need to maintain it for every extension.

Extending MachineImage and MachineType Section

Instead of explicitly introducing a bastion field to the CloudProfile we could also go for a more general approach. What we need mainly need is the machineImage and machineType. We could for example introduce some flag like default to the machineImages section, which specifies the image family to use:

...
machineImages:
  - name: gardenlinux
    updateStrategy: minor
    default: true
    versions:
    - architectures:
      - amd64
      - arm64
...

From this image family we would take the first supported.

Likewise we would add a flag smallest for machineTypes to identify the machine type to be used when creating the bastion:

...
machineTypes:
  - architecture: amd64
    cpu: "2"
    gpu: "0"
    memory: 4Gi
    name: g_c2_m4
    storage:
      class: standard
      size: 64Gi
      type: default
    usable: true
    smallest: true
...

This approach could also be beneficial for other consumers as well. For example the Dashboard could prefill fields with those values. The disadvantage is that the bastion configuration is not explicit and therefore cannot be directly changed without possible side effects.