Skip to main content
Version: 0.9

Cluster Plans

Cluster plans provide platform operators the means to shape the options and configuration available for teams to self-serve their environment. You can specify kubernetes versions, node pools and instance types, provider features such as GKE Autorepair and autoscaling, as well as options related to default roles the teams inherit.

#Display a list of all plans in Kore
$ kore get planRESOURCE                 SUMMARY                                                                DESCRIPTION                KIND    AGEaks-development          Provides a development AKS cluster                                     AKS Development Cluster    AKS     27daks-production           Provides a production AKS cluster                                      AKS Production Cluster     AKS     27deks-development          Provides a development cluster within EKS                              EKS Development Cluster    EKS     125deks-production           Provides a production cluster within EKS                               EKS Production Cluster     EKS     125dgke-budget-cluster       Provides a cheap cluster using pre-emptible nodes, good for testing    GKE Budget Cluster         GKE     30dgke-development          Provides a development cluster within GKE                              GKE Development Cluster    GKE     133dgke-production           Provides a production cluster within GKE                               GKE Production Cluster     GKE     133d

From the UI navigate to plans via Configure > Cloud > Provider > Cluster Plans. By default, all teams can access all plans, however if you have configured Kore cloud account automation you can restrict this by only including certain plans in the naming rules.

Benefits of cluster plans#

Cluster plans:

  • Provide sane default settings out of the box that reflect best practices for production and nonproduction environments.
  • Remove the need for domain knowledge in development teams. They can focus on deploying their applications to staging, dev, and production environments, rather than on Kubernetes cluster types.
  • Provide guard rails for the environment options teams can select to keep infrastructure in line with the organization's requirements.

Once the plans are set up teams can consume them when building their environment, for example:

kore create cluster CLUSTER-NAME --plan gke-development 

Cluster security#

We have followed guidelines published by the cloud providers for configuring clusters:

  • Removing any loose permissions bindings
  • Removing previous pod security policies and defaulting all applications to least privileged kore.default policies
  • Enforcing a default denial on all namespaces created—ensuring traffic is explicitly permitted rather than a wildcard to all

Cluster plan policies#

Providing options is great, but teams may need to override from the norm. Plan policies provide the means for platform operators to say certain options can be overridden by the team while others cannot, e.g. you can allow the team to add another node pool, change the machine type, or set the network CIDR permitted to access the API.

$ kore get planpolicyRESOURCE                       SUMMARY                                 DESCRIPTION                                                                            AGEallow-gke-node-type-changes    Allow GKE node type changes                                                                                                    86ddefault-aks                    Default plan policy for AKS clusters    This policy defines which plan properties can be edited by default for AKS clusters    27ddefault-eks                    Default plan policy for EKS clusters    This policy defines which plan properties can be edited by default for EKS clusters    127ddefault-gke                    Default plan policy for GKE clusters    This policy defines which plan properties can be edited by default for GKE clusters    127drestrict-ip-editing            Restrict IP Editing                     Teams with this policy applied cannot edit IP ranges                                   86d
$ kore get planpolicy restrict-ip-editing -o yamlapiVersion: config.kore.appvia.io/v1kind: PlanPolicymetadata:  name: restrict-ip-editing  namespace: kore-adminspec:  description: Teams with this policy applied cannot edit IP ranges  kind: GKE  properties:  - allowUpdate: false    disallowUpdate: true    name: authorizedMasterNetworks  summary: Restrict IP Editing

You can define and edit policies using the UI via Configure > Cloud > Provider > Cluster Policies.

All properties default to read-only, then the default policies which ship with Kore enable editing on a number of fields. You can define additional policies to restrict or widen the fields which teams can edit.

Each policy can be applied to either all teams, or one or more specified teams, allowing you to permit specific teams greater control if needed.

An explicit deny cannot be overridden, so if you set a global deny for a field, you cannot override that for a specific team. Instead, leave it unspecified at the global level (which will make it read-only by default), then create a policy to allow that field to be edited for the team you wish.

Last updated on Aug 5, 2021