Reprise du message précédent :
et les workspaces ?

Pour les tfstates

wat

Pour la gestion des secrets utilisés dans terraform, vous utilisez quoi ?
J'hésite à tester HC Vault la

Azure Keyvault si le backend est dans Azure, sinon HC Vault

Non on est chez AWS et GCP. Du coup j'utilise le store manager du backend que j'utilise ?

sur GCP j'utilise secret manager

J’aime bien Vault parce que justement ça marche partout.
 
Par contre, en version CE c’est « chiant » de gérer le unseal, je mets des trucs un peu limite en place pour contourner…

Détaille, c'est quoi ce unseal, et tes trucs limite ?
J'aimerais tester parce que c'est un nom qu'on retrouve souvent mais ça a pas l'air uber léger.

C'est quoi cet IMDSv2 qui me spam la https://aws.amazon.com/fr/blogs/sec [...] structure/

C'est le déverrouillage du vault

Envoy : https://youtu.be/r7HV4s-4ksQ?si=hx-jBNkF6Ejl63Dp
 
Les vidéos de Kevin Fang sont énormes  

Bah en gros avec la version gratuite soit t'as un KMS, soit un deuxième vault (et tu les configures de façon croisée), soit tu déverrouilles par l'API

Moi qui me prends la tete pour savoir comment protéger les secrets avec à chaque fois la conclusion que tout est facilement niquable si y a du deverrouillage auto, tombe sur cet article sur reddit :
https://www.macchaffee.com/blog/2022/k8s-secrets/

et la partie qui fait mal :

Y'a plusieurs choses avac vault, l'unseal, la méthode l'accès au vault en lui-même, les droits donnés dans le vault...
 
Pour l'accès au vault, tu as des possibilités qui évitent de stocker un token quelque part.
Avec GitLab, tu as par exemple l'authentification JWT : telle branche de tel projet de tel GitLab peut récupérer des secrets dans tel chemin de tel secret engine du vault.
 
L'auto unseal n'est pas obligatoire, tu peux très bien te contenter de surveiller /v1/sys/seal-status, créer un ticket et attendre qu'un humain unseal le vault.
Bon faut quand même stocker les clés quelque part
 
Mais c'est vrai qu'avec vault tu peux vite tomber dans la facilité : méthode d'authentification qui n'expire pas, access policy open bar, et auto unseal avec du bricolage...

Bonjour ici,  
 
Petite question qui, je l'espère, à sa place ici : je suis en train d'essayer de configurer un reverse tunnel SSH.
 
J'utilise la commande suivante depuis la machine A (localhost) vers la machine B (84.84.84.84) et cela fonctionne. J'utilise le -p 2222 qui est forwardé vers le port 22 de la machine B
 

 
Une fois sur la machine B, j'exécute la commande suivante pour accéder à machine A :  
 

 
Malheureusement, je reçois le message suivant :

 
J'ai mal compris quelque chose ?  
 
Merci

Pourquoi tu refait un ssh sur le 9300 ? Tu as un serveur ssh en écoute sur ce port sur A ?

Non, c'est le port classique (22) qui écoute sur la machine A
 
Je pensais qu'il fallait utiliser le port 99300 sur machine B pour forwarder vers machine A ?

Lis un random tuto de reverse tunnel.
Si tu prend ta commande :
ssh -R *:9300:localhost:9300 user@84.84.84.84 -p 2222

ssh : tu appels le client ssh sur A pour établir une connexion
-R tu va, dans cette connexion, ajouter un port forwarding inverse : un port de A, qui sera accessible depuis un port de B
*:9300 : sur n'importe quelle IP de B, le tunnel ecoutera sur le port 9300
localhost : l'extrémité locale du tunnel (côté A), c'est localhost (donc A).
:9300 sur le port 9300 de A
user : le compte utilisé pour se connecter à B
84.84.84.84, l'ip utilisée pour se connecter à B
-p 2222 le port où le service ssh écoute sur B.

En conséquence, une fois que tu t'est connecté avec la commande au dessus et que le terminal est ouvert, sur B, tu peux te connecter à localhost:9300. Le trafic sera transmis automatiquement au port 9300 de A.

Question kube @ gcp (GKE) :
Pourquoi un private ou un public cluster ? ça change quoi d'avoir un endpoint publique sur le control plane ? (je crois avoir la réponse en écrivant )
vous utilisez gateway api ? ingress object ? des NEG ?
 
sinon si vous avez un exemple de vos clusters sous terraform je veux bien voir ça

 
https://registry.terraform.io/modul [...] gle/latest
 
GKE private ici, afin de ne pas exposer le control plane sur le net (même si tu peux whitelister des ips..)
Par contre pour les déploiements GKE avec cloudbuild, je dois utiliser un pool privé et passer par une VM avec un tiny-proxy. C'est bien relou, mais bon ça fonctionne....

CloudBuild c'est du CI/CD GCP ? Builder une image, pusher dans le registry et monter le service ?
J'utilise GHA pour ça et pour ECS/Fargate je crois que j'ai utilisé un worker gha sur une de mes vms pour accéder au privé ? Pas sur mais je me souviens avoir des soucis en essayant de whiterlister GHA (qui a genre 234020420402 subnets).
A la limite si je pouvais knocker sur une API avec un token dans GH Secrets et ouvrir l'IP du worker gha pour accéder au control plane ça serait cool
 
Une petite question débile en passant, c'est quoi la différence entre le provider gcp qui me permet de monter/set le cluster gke et le module que tu link ?

GHA ?
 
Avec cloudbuild on build des images, mais on fait aussi des déploiements (dans gke, cloudrun...)
 
Le module que je link est le module terraform qui permet de builder un GKE sans trop se faire chier.
 
Ca t'évite de faire le code TF pour déployer un GKE, SA, règles de FW, nodepool....

Github Actions
Ah du coup c'est un orchestrateur cloudbuild aussi ?

Pour le module, je vais m'y plonger

ce sont des runners qui permettent de lancer des actions, comme gitlab/github runner

C'est sympa ? Ton code est où ?
Au passage c'est quoi ton discriminant entre pousser ton ct sur cloudrun ou gke ?

Imaginons un dépôt git avec 2/3 merdes de développeurs, ils veulent pousser ça sur un CloudRun pour tester leur merde, ils définissent leur petit service, la taille du/des containers, etc. Ils veulent pousser avec un workflow préfait par GCP ok.
Mais comment je gère ça avec terraform au passage ?
 
* Un workflow qui génère ça sur le dépôt TF et qui à son tour va déployer ça ?
* osef ?
* la merde du dev sur un cluster gke private pour dev ?
* osef ?
* tout ce qui cloudrun = pas géré par tf ?
 
J'essaie de pousser pour TOUT gérer via TF, j'ai encore du mal à convaincre pour le quart restant de l'infra

Pour ma part la cloud run est créée avec terraform (+ LB, SA...) et les dev ne font qu'un gcloud run deploy .... dans leur pipline a eux.
 
Et dans TF il faut avoir l'ignore qui va bien pour ne pas prendre en compte le changement de l'image utilisée.
 
Le TF est dans un repo dédié auu projet, et le code des dev dans un autre repo.

J'ai une question sur ssh et proxycommand avec gloud
 
J'utilise le VPN du pauvre (sshuttle) pour accèder a mes ressources GCP, en passant par une VM derrière cloud IAP et du 2FA en plus.
 
Mon config ssh ressemble à ça :
 

 
Si je fais un ssh bastion-dev, je vais me taper 2 fois l'auth 2FA, car le hostname change
 

• mon_user@compute.023558751574876 => prompt pour 2FA
• mon_user@bastion-dev.local => prompt pour 2FA

Et je suis dans la matrice
 
Mais cette double auth 2FA me fait un peu chier.
 
Une idée ?
 
Edit : la ligne Hostname n'est même pas nécessaire j'ai l'impression, mais j'ai tjrs le souci sans

Conférences re:invent AWS 2023 (passées il y'a peu)

• Avec l'arrivée de Graviton 4 (instanves r8g), vous pensez qu'on aura du t5g ou autre soon ?
• Sinon vous avez vu des annonces ou des confs intéréssantes à re:invent AWS 2023 ? Voilà ce qui en est sorti niveau produits.

J'insère   mon secret dans Google Secret Manager avec Terraform sous la forme d'un fichier/base64. Mais je ne le suis pas via versionning parce que secret. Mais TF le veut bah parce qu'il a commencé comme ça, il aime bon son fichier, lui il le suit toosa
Du coup je vois pas trop comment insérer un secrets sans l'avoir dans le tf ou suivre un fichier qu'on peut pas suivre avec git
une var et tfvars ?

edit:

edit:
Bon j'ai du ajouter un lifecycle ignore_changes sur secret_data, j'ai viré la logique de count, j'ai tenté d'utiliser locals pour je ne sais plus quoi et au final j'ai utilisé la logique if file exists then apply sinon null dans secret_data

• Encore 15hr pour des prix bas sur les formations & certifications Linux Foundation https://training.linuxfoundation.org/cyber-monday-2023/

J'ai ma LFCE a renouveler, elle a expiré samedi, mais j'ai un peu ma flemme j'avoue...

Difficile à passer ? Je n'ai pas de liquidités pour prendre quoi que ce soit là, c'est dommage

J'avais pas trouvé ça très simple en effet . C'est assez large et time constrained donc faut être efficace et rapide .
Donc si tu bosses tous les jours sur linux, que tu maitrises les commandes, les options and co ça se fait bien mais faut pas perdre de temps.
 
C'est pas donné donné, je sais pas si ça a une grosse plu value professionnellement parlant, moi j'aime bien ça me permet de me maintenir et pratiquer et en tant que freelance ça peut faire une ptite différence.
Après je passe ça en charge dans la boite et zou . Tout comme l'abo kodecloud par exemple

Elle semble plus dispo : https://training.linuxfoundation.org/lfcecert-inactive/
 

Ah bah ça règle le problème
En effet https://www.reddit.com/r/sysadmin/c [...] e_retired/
 
Pas sûr de vouloir faire la LFCS ou LFCT, à voir si c'est intéressant côté RedHat
 
Faut que je regarde qd expire ma CKA, ça doit être la prochaine sur ma liste.

RHCE a beaucoup changé depuis la version 8, c'est très axé Ansible alors qu'auparavant du avais du TLS, iSCSI, SELinux, ACLs, DNS, etc.

Encore une question terraform. J'ai un dossier tf avec son tfstate qui génère in fine des nouvelles routes et qui cherche à les les déployer sur les vpc/sb/rt appropriés. A côté j'ai un autre dossier tf avec son propre tfstate qui s'occupe du network d'un cloud provider par exemple.
Au début je pensais aller taper dans le tfstate de l'autre en remote pour modifier la route mais ça n'a pas l'air d'être une pratique standard => mauvaise idée.
Puis je me suis souvenu que taper dans du remote tfstate autre ça serait plutôt pour du read-only, ok.

• Par contre comment je déploie mes routes ? Il y'a peut-être une histoire de module(s) à gérer ici mais je n'appréhende pas encore correctement cette partie là.
• Ou alors je merge mon projet1 dans le projet2 ?

J’ai eu le même problème et j’en suis venu à la conclusion que le mieux c’était de gérer dans le même projet.  
Y’a ptet toujours moyen d’aller peut être faire des imports dans ton tfstate mais je pense que c’est pas une bonne approche.

Je vais réfléchir à la méthode des imports mais ça m'a pas l'air super dynamique. Je pensais réfléchir à ajouter un ignore_changes mais ça risque aussi de péter l'intérêt de la gestion des routes via les projets de chaque provider.
Il y'a ça aussi, j'ai un projet pour chaque provider, difficile d'intégrer le 3ème projet dans l'un ou l'autre puisqu'il génère des routes sur les 2.
Je discute avec GPT4 là et il a l'air chaud pour une histoire de module