For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/fr/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/fr/llms-full.txt, and this page is available as Markdown at https://docs.ovhcloud.com/fr/guides/public-cloud/containers-orchestration/managed-kubernetes/change-security-update.md.

Changer la politique de mise à jour de sécurité sur un cluster OVHcloud Managed Kubernetes

Voir en Markdown

Découvrez comment changer la politique de mise à jour de sécurité sur un cluster OVHcloud Managed Kubernetes

Objectif

Le service OVHcloud Managed Kubernetes vous fournit des clusters Kubernetes sans les contraintes liées à leur installation ou à leur exploitation. Chez OVHcloud, nous souhaitons vous proposer les meilleurs produits et services. Pour nous, la sécurité est essentielle, c'est pourquoi nous appliquons par défaut les mises à jour de sécurité sur vos clusters Kubernetes.
Vous pouvez néanmoins modifier la configuration de la politique de mise à jour de sécurité de votre cluster. Découvrez comment procéder dans ce guide.

Prérequis

  • Un cluster OVHcloud Managed Kubernetes

Accès à l'espace client OVHcloud

  • Lien direct :
  • Pour accéder à vos services : Public Cloud > Sélectionnez votre projet > Managed Kubernetes Service

En pratique

Configurer la politique de mise à jour de sécurité via l'espace client OVHcloud

Cliquez sur le bouton ... à droite de votre cluster Kubernetes et choisissez Gérer le cluster.

Dans la section Management, cliquez sur Changer la politique de sécurité.

Une fenêtre pop-up affiche toutes les options disponibles :

  • Ne pas mettre à jour (NEVER_UPDATE). Nous ne recommandons pas ce choix. OVHcloud se réserve le droit de mettre à jour les composants Kubernetes ou vos nœuds à titre exceptionnel, dans des cas critiques qui limitent la sécurité de notre infrastructure.

  • Indisponibilité minimale (MINIMAL_DOWNTIME). Applique les mises à jour de sécurité (« patch version ») à votre service Kubernetes, afin de garantir la sécurité et la stabilité du service. Si nous ne pouvons pas éviter une interruption de service lors d'une mise à jour progressive (rolling update) de vos nœuds, nous vous en informerons. Nous vous conseillons de dimensionner votre cluster afin qu'il puisse être mis à jour à tout moment.

  • Sécurité maximale (ALWAYS_UPDATE). Applique les mises à jour de sécurité (« patch version ») à votre service Kubernetes, afin de garantir la sécurité et la stabilité du service. La mise à jour peut entraîner l'indisponibilité de vos nœuds pendant quelques minutes, le temps d'effectuer la mise à jour progressive (rolling update).

La politique de sécurité Sécurité maximale est configurée par défaut. Même si nous recommandons la sécurité maximale, vous pouvez choisir la politique de sécurité qui vous convient.

Choisissez une option et cliquez sur Confirmer.

Configurer la politique de mise à jour de sécurité via Terraform

Depuis la version 0.20 et supérieures de notre provider Terraform OVH, vous pouvez configurer la politique de mise à jour de sécurité à la création du cluster, ainsi qu'à sa mise à jour, également via Terraform.

Récupérer les informations de votre cluster et de vos tokens API

Le « provider OVH » doit être configuré avec un ensemble d'identifiants :

  • une application_key
  • un application_secret
  • une consumer_key

Pourquoi ?

Parce que, en arrière-plan, le « provider Terraform OVH » effectue des requêtes vers les API OVHcloud.

Pour récupérer ces informations nécessaires, suivez notre tutoriel Premiers pas avec les API OVHcloud.

Plus précisément, vous devez générer ces identifiants via la avec les droits suivants : GET, POST, PUT et DELETE sur /*.

Lorsque vous avez généré vos tokens OVHcloud avec succès, veillez à les enregistrer, car vous devrez les utiliser très prochainement.

La dernière information nécessaire est le service_name : il s'agit de l'identifiant de votre projet Public Cloud.

Comment l'obtenir ?

Dans la section Public Cloud, vous pouvez récupérer l'identifiant de votre service grâce au bouton Copier dans le presse-papier.

Vous utiliserez également cette information dans les fichiers de définition des ressources Terraform.

Instructions Terraform

Commencez par créer un fichier provider.tf avec la version minimale, l'endpoint européen (« ovh-eu ») et les clés précédemment récupérées dans ce guide.

Terraform 0.13 et versions ultérieures :

terraform {
  required_providers {
    ovh = {
      source  = "ovh/ovh"
    }
  }
}

provider "ovh" {
  endpoint           = "ovh-eu"
  application_key    = "<your_access_key>"
  application_secret = "<your_application_secret>"
  consumer_key       = "<your_consumer_key>"
}

Terraform 0.12 et versions antérieures :

# Configure the OVHcloud Provider
provider "ovh" {
  endpoint           = "ovh-eu"
  application_key    = "<your_access_key>"
  application_secret = "<your_application_secret>"
  consumer_key       = "<your_consumer_key>"
}

Les clés secrètes peuvent également être récupérées depuis votre environnement.

  • OVH_ENDPOINT
  • OVH_APPLICATION_KEY
  • OVH_APPLICATION_SECRET
  • OVH_CONSUMER_KEY

Cette dernière méthode (ou une alternative similaire) est recommandée pour éviter de stocker des données secrètes dans un dépôt source.

Nous avons ici défini l'endpoint ovh-eu, car nous souhaitons appeler l'API OVHcloud Europe, mais d'autres endpoints existent selon vos besoins :

  • ovh-eu pour l'API OVHcloud Europe
  • ovh-us pour l'API OVHcloud US
  • ovh-ca pour l'API OVHcloud Amérique du Nord

Ensuite, créez un fichier variables.tf avec service_name :

variable service_name {
  type        = string
  default     = "<your_service_name>"
}

Définissez les ressources que vous souhaitez créer dans un nouveau fichier nommé ovh_kube_cluster.tf :

resource "ovh_cloud_project_kube" "cluster" {
  service_name = var.service_name
  name         = "my-super-cluster"
  region       = "GRA5"
  version      = "1.31"

  update_policy = "NEVER_UPDATE" # "ALWAYS_UPDATE" by default but you can choose also "MINIMAL_DOWNTIME" or "NEVER_UPDATE"
}

Dans cette configuration de ressources, nous demandons à Terraform de créer un cluster Kubernetes, dans la région GRA5, avec la version Kubernetes 1.31 (la dernière version recommandée au moment de la rédaction de ce tutoriel), avec une politique de mise à jour de sécurité équivalente à « Ne pas mettre à jour ».

Nous devons maintenant initialiser Terraform, générer un plan, puis l'appliquer.

$ terraform init

Initializing the backend...

Initializing provider plugins...
- Finding latest version of ovh/ovh...
- Installing ovh/ovh v0.20.0...
- Installed ovh/ovh v0.20.0 (signed by a HashiCorp partner, key ID F56D1A6CBDAAADA5)

Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://www.terraform.io/docs/cli/plugins/signing.html

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

La commande init initialise votre répertoire de travail qui contient les fichiers de configuration .tf.

C'est la première commande à exécuter pour une nouvelle configuration, ou après avoir effectué un checkout d'une configuration existante depuis un dépôt git par exemple.

La commande init va :

  • Télécharger et installer les providers/plugins Terraform
  • Initialiser le backend (si défini)
  • Télécharger et installer les modules (si définis)

Nous pouvons maintenant générer notre plan :

$ terraform plan

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # ovh_cloud_project_kube.cluster will be created
  + resource "ovh_cloud_project_kube" "cluster" {
      + control_plane_is_up_to_date = (known after apply)
      + id                          = (known after apply)
      + is_up_to_date               = (known after apply)
      + kubeconfig                  = (sensitive value)
      + name                        = "my-super-cluster"
      + next_upgrade_versions       = (known after apply)
      + nodes_url                   = (known after apply)
      + region                      = "GRA5"
      + service_name                = "xxxxxxxxxxxxxxxxxxxx"
      + status                      = (known after apply)
      + update_policy               = "NEVER_UPDATE"
      + url                         = (known after apply)
      + version                     = "1.31"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if you run "terraform apply" now.

Grâce à la commande plan, nous pouvons vérifier ce que Terraform souhaite créer, modifier ou supprimer.

Le plan nous convient, appliquons-le donc :

$ terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # ovh_cloud_project_kube.cluster will be created
  + resource "ovh_cloud_project_kube" "cluster" {
      + control_plane_is_up_to_date = (known after apply)
      + id                          = (known after apply)
      + is_up_to_date               = (known after apply)
      + kubeconfig                  = (sensitive value)
      + name                        = "my-super-cluster"
      + next_upgrade_versions       = (known after apply)
      + nodes_url                   = (known after apply)
      + region                      = "GRA5"
      + service_name                = "xxxxxxxxxxxxxxxxxxxx"
      + status                      = (known after apply)
      + update_policy               = "NEVER_UPDATE"
      + url                         = (known after apply)
      + version                     = "1.31"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

ovh_cloud_project_kube.cluster: Creating...
ovh_cloud_project_kube.cluster: Still creating... [10s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [20s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [30s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [40s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [50s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [1m0s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [1m10s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [1m20s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [1m30s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [1m40s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [1m50s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [2m0s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [2m10s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [2m20s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [2m30s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [2m40s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [2m50s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [3m0s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [3m10s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [3m20s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [3m30s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [3m40s elapsed]
ovh_cloud_project_kube.cluster: Creation complete after 3m47s [id=76db2764-58d2-4384-b17f-ab38b0c7fc78]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Mise à jour

Parce que la sécurité est importante, si vous souhaitez mettre à jour la politique de sécurité, vous pouvez également le faire via Terraform. Modifiez le fichier ovh_kube_cluster.tf avec ce contenu :

resource "ovh_cloud_project_kube" "cluster" {
  service_name = var.service_name
  name         = "my-super-cluster"
  region       = "GRA5"
  version      = "1.31"

  update_policy = "ALWAYS_UPDATE" # "ALWAYS_UPDATE" by default but you can choose also "MINIMAL_DOWNTIME" or "NEVER_UPDATE"
}

Puis appliquez-le :

$ terraform apply
ovh_cloud_project_kube.cluster: Refreshing state... [id=xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # ovh_cloud_project_kube.cluster will be updated in-place
  ~ resource "ovh_cloud_project_kube" "cluster" {
        id                          = "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx"
        name                        = "my-super-cluster"
      ~ update_policy               = "NEVER_UPDATE" -> "ALWAYS_UPDATE"
        # (10 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

ovh_cloud_project_kube.cluster: Modifying... [id=xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx]
ovh_cloud_project_kube.cluster: Modifications complete after 1s [id=xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx]

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

Destruction

Si vous souhaitez supprimer le cluster Kubernetes que vous avez ajouté via Terraform, vous devez exécuter la commande terraform destroy :

$ terraform destroy
ovh_cloud_project_kube.cluster: Refreshing state... [id=xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  - destroy

Terraform will perform the following actions:

  # ovh_cloud_project_kube.cluster will be destroyed
  - resource "ovh_cloud_project_kube" "cluster" {
      - control_plane_is_up_to_date = true -> null
      - id                          = "xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx" -> null
      - is_up_to_date               = true -> null
      - kubeconfig                  = (sensitive value)
      - name                        = "my-super-cluster" -> null
      - next_upgrade_versions       = [] -> null
      - nodes_url                   = "xxxxxx.nodes.c3.gra.k8s.ovh.net" -> null
      - region                      = "GRA5" -> null
      - service_name                = "xxxxxxxxxxxxxxxxx" -> null
      - status                      = "READY" -> null
      - update_policy               = "ALWAYS_UPDATE" -> null
      - url                         = "xxxxxx.c3.gra.k8s.ovh.net" -> null
      - version                     = "1.31" -> null
    }

Plan: 0 to add, 0 to change, 1 to destroy.

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

ovh_cloud_project_kube.cluster: Destroying... [id=xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx]
ovh_cloud_project_kube.cluster: Still destroying... [id=xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx, 10s elapsed]
ovh_cloud_project_kube.cluster: Still destroying... [id=xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx, 20s elapsed]
ovh_cloud_project_kube.cluster: Still destroying... [id=xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx, 30s elapsed]
ovh_cloud_project_kube.cluster: Destruction complete after 37s

Destroy complete! Resources: 1 destroyed.

Aller plus loin

Pour obtenir une vue d'ensemble du service OVHcloud Managed Kubernetes, consultez la page OVHcloud Managed Kubernetes.

Pour en savoir plus sur l'utilisation pratique de votre cluster Kubernetes, nous vous invitons à consulter nos tutoriels.

  • Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page Professional Services pour obtenir un devis et faire analyser votre projet par nos experts.

  • Échangez avec notre communauté d'utilisateurs.

Cette page vous a-t-elle aidé ?