L’usage du cloud dans les entreprises ne fait plus débat. Bien utilisé, il devient moteur d’avantages concurrentiels et ouvre la voie à de nouvelles perspectives de marché.
Migrer sur le cloud doit cependant répondre à certaines exigences que l’on rencontre en entreprise. En particulier le besoin de conformité.
Les principaux fournisseurs cloud y répondent avec des “organisation policies” qui contraignent les actions possibles du point de vue du consommateur de la plateforme. Des services comme AWS config vous remonteront en complément des alertes sur des règles prédéfinies.
Pourtant ces solutions sont limitées par leur forte corrélation à une vision du fournisseur Cloud qui ne peut prendre en compte les besoins de chacun.
Pour dépasser cette limitation, une première approche pallie ce manque par la création de workloads spécifiques plus ou moins chorégraphiées entre elles afin de se conformer à une règle légale ou business propre à chaque métier.
Cette approche manuelle fonctionne sur de simples cas d’usage mais scale difficilement à l’échelle d’un groupe.
C’est dans ce contexte que l’outil Cloud Custodian (c7n) apporte des pistes intéressantes. En définissant un Domain Specific Language qui s'appuie sur des services du cloud cible, c7n abstrait la mise en place d’une politique de conformité. À travers un exemple concret de Finops, cet article met en lumière les avantages d’une approche déclarative dans le traitement de la conformité pour enfin l'interpréter à travers le prisme d’une approche Cloud Native.
Nous le présentions déjà dans un précédent article, Cloud Custodian ou c7n, est un outil de Compliance As Code qui grâce à un DSL Yaml va se brancher aux principaux cloud publics pour en garantir un certain comportement. Son nom se veut explicite puisqu’il vient du latin custodia : littéralement garder, surveiller.
Notons qu’il ne s’agit pas d’une simple question d’interdiction de création de ressource. L’IAM y répond déjà. Ce qui nous intéresse c’est bien la conformité de la création de ressources par rapport à certaines règles. Par exemple, le fait que toute ressource doit être labellisée avec une regexp particulière.
En considérant votre plateforme cloud comme un jeu de plateau, c7n correspondra à vos règles du jeu. Ce n’est pas ce qui vous empêchera de jouer, mais ce sera ce qui vous contraindra dans les coups possibles.
En filigrane apparaît une réponse au modèle de responsabilité partagée que mettent en avant les fournisseurs Cloud. Globalement traduit par “responsable de l’infrastructure mais pas du contenu hébergé, ni de son accès”, c7n rend explicite les règles s’appliquant dans le cadre de la responsabilité du consommateur cloud.
Dans un précédent article, nous parlions déjà de Cloud SQL. Nous l’y présentions comme un service GCP managé de base de données relationnelles. Le côté managé s’y traduit notamment par la gestion de l’instance et du réseau sous-jacent par le fournisseur de service.
Toutefois ce service n’est pas à ranger dans la catégorie serverless comme pourrait l’être d’autres services de données tels GCS, Datastore ou BigQuery. Autrement dit, la facturation ne se fait pas à l’utilisation effective de la base de données mais au temps d’existence des instances qui la supportent.
Or, il est assez courant, dans une démarche de test, de provisionner des instances utilisées uniquement durant les horaires de bureau. Toutefois, celles-ci resteront actives en dehors de ces horaires, continuant à coûter pour rien.
La calculatrice GCP explicite ce qu’il est possible d’économiser sur un mois avec une base de 730 heures (24/24h, 7/7j) opposée à 217 heures (horaire de bureaux et hors week-end, soit à peu près 70% de temps en moins). En ordonnée de gauche se trouve le coût mensuel et les économies sur la droite.
Les abscisses alternent VCpu (type d’instance derrière la BDD) et capacité de la BDD.
Ces graphiques démontrent que le compute est plus déterminant que la capacité de stockage dans le coût mensuel de cloud SQL. D’autre part, il n’y a pas de corrélation forte entre le temps d’extinction à 70% et la réduction de la facture qui peut “n’être” que de 26%. Cela dit, au-delà de la facturation il y a aussi et surtout un sujet de conformité pour par exemple s’assurer de l’application d’un droit à la déconnexion en entreprise.
L’idée de se servir de services serverless pour résoudre ce problème Finops est plutôt intéressante. Par définition, cette approche n’implique qu’un surcoût opérationnel ou financier minime.
Il n’est donc pas étonnant de voir de telles solutions se mettre en place dans la communauté GCP.
La plus courante consiste à combiner l’usage du Cloud Scheduler avec des cloud functions.
Le premier déclenchera une exécution récurrente du second, chargé d’éteindre ou d’allumer les instances cloud SQL visées selon des horaires définis. On pensera à un outil comme Terraform pour mettre en place cette approche.
Nous avons mentionné l’aspect coût de run intéressant. Ajoutons que, dans l’esprit GCP, cette méthode est tout indiquée pour quelqu’un habitué à penser Serverless.
Nous sommes loin des approches consistant à provisionner un thread de surveillance permanent dans une instance de compute dont la gestion est à notre charge. Autrement dit, nous utilisons correctement la boîte à penser offerte par la GCP.
Malgré le côté tout indiqué de cette approche, il demeure des points gênants. En premier lieu, l’architecture n’est pas standard. Ce que nous proposons dans cet article est subjectif. On pourrait avoir une approche différente pour un résultat similaire.
Second point, le développement itératif et le maintien en conditions opérationnelles de la solution engageront certainement des ressources plus ou moins importantes. On réduit alors d’autant les économies de facturation qui sont à l’origine de la mise en place de cette solution en augmentant le Total Cost of Ownership.
C’est là que se trouve l’élégance du paradigme déclaratif : la complexité opérationnelle de la solution est à la charge du fournisseur de celle-ci. Il ne reste donc plus qu’à mobiliser des ressources sur la production de règles centrées sur la résolution du vrai problème. Ces tâches peuvent être prises en charge par des spécialistes du domaine de la compliance directement et non obligatoirement par des profils techniques.
Vous l’aurez compris, notre accroche précédente permet d’introduire l’implémentation du besoin avec Cloud Custodian.
Voici le code yaml nous permettant de répondre au besoin de manière expressive.
policies:
- name: sql-instance-stop
description: |
check basic work of Cloud SQL filter on instances: stop instances daily
resource: gcp.sql-instance
filters:
- type: value
key: state
op: equal
value: RUNNABLE
#- [more-filtering-conditions]
mode:
type: gcp-periodic
schedule: 0 18 * * *
service-account: 'custodian-tests@example.iam.gserviceaccount.com'
actions:
- type: stop
- name: sql-instance-start
description: |
check basic work of Cloud SQL filter on instances: start instances daily
resource: gcp.sql-instance
filters:
- type: value
key: state
op: equal
value: STOPPED
#- [more-filtering-conditions]
mode:
type: gcp-periodic
schedule: 0 8 * * *
service-account: 'custodian-tests@example.iam.gserviceaccount.com'
actions:
- type: start
Le code est compréhensible même pour un non initié à c7n, illustrant par là parfaitement le paradigme déclaratif. Notons que nous l'avons simplifié pour ne pas noyer le lecteur.
Voici concrètement ce qui se passe dans les coulisses :
c7n ne fait pas plus qu’implémenter, selon la vision architecturale de sa communauté, ce que nous avons évoqué plus tôt. Il se trouve que cette solution est strictement équivalente à la partie chorégraphiée. Pourtant la différence est profonde : à aucun moment nous n’avons dû nous soucier de cette architecture. Toute la boilerplate et le testing sont à la charge de c7n.
L’outil étant open source, il est plutôt simple d’y contribuer. C’est d’ailleurs ce que nous avons fait pour rendre possible ce cas d’usage.
Cette fois, l’expression du besoin vaut pour implémentation. Le Domain Specific Language associé reste compréhensible même pour quelqu’un n’ayant pas utilisé c7n.
En appliquant cette approche sur l’ensemble des politiques de nos plateformes cloud, nous l’auto-documentons en quelque sorte.
Mieux, nous fournissons des interfaces beaucoup plus standards pour des audits et donc la garantie d’une conformité.
Pour aller plus loin, si l’on suit l’addage “Quis custodiet ipsos custodes”, littéralement “qui garde les gardiens ?”, nous pouvons imaginer utiliser CUE pour définir des contraintes de cohérence sur les politiques définies par c7n.
Comme tout outil open source, c7n évolue grâce à sa communauté. Plutôt très bien implantée sur les providers AWS et Azure, elle est encore qualifié de "alpha'' sur la GCP et ne prend tout simplement pas en charge d’autres cloud providers. On notera aussi une documentation qui peut gagner en clarté. Voilà sur la forme.
Sur le fond certains points sont à avoir en tête.
Tout d’abord, c7n n’est pas autoportant. Il requiert l’existence d’un certain nombre de ressources sur la plateforme qu’il surveille et qu’il faudra donc créer au préalable. Citons par exemple des topics pub/sub, des activations d’API, des comptes de services, etc. Des outils d'IaC complèteront bien son action.
Cotés ressources créées c7n les labelisent par défaut ou suit une convention de nommage mais il n'est pas toujours possible d'override les valeurs par défaut. Pour cela l'utilisateur devra passer par des règle c7n supplémentaire dont l'action sera de labeliser. On aurait bien vu cette action se définir directement dans la définition d'une policy. Potentiellement plus problématique, le déploiement des policies demandes des permissions assez larges mais nous retrouvons les mêmes contraintes qu'avec des outils comme Terraform.
On retiendra donc que l’usage de c7n appelle un besoin d’Infrastructure As Code qui n’est pas fourni par l’outil et qui implique des compléments de solution.
D’une certaine manière, c7n vous offre un Minimum Viable Product qu’il vous faudra potentiellement enrober d’une couche d’orchestration. Des implémentations sont offertes par la communauté mais ciblent un provider et des besoins particuliers qui ne correspondent pas forcément aux vôtres.
Il n’est pas impossible de voir dans le futur c7n servir de base à une offre entreprise qui comblera ces manques. Ce sont des schémas qui existent et qui ont fait leurs preuves (cf Amundsen et Steema, Terraform et Terrarform Cloud).
Reste à voir si les marchés répondront favorablement à ce genre d’initiative.
D’un point de vue purement technique, les deux approches peuvent prétendre au qualificatif de Cloud Native. Nous nous basons sur des technologies managées gérant quasiment tous les aspects opérationnels à notre place qui rendent l’approche robuste vis-à-vis des indéterminismes propres au cloud. Scalabilité, bande passante, provisionning de resource, sécurité sont autant de points dont vous n’aurez pas à vous soucier.
Néanmoins, le Cloud Native n’est pas à comprendre uniquement du point de vue technique.
La scalabilité s’applique aussi d’un point de vue maintenance, organisation et documentation. Tous ces aspects doivent aussi s’adapter au fait que nous sommes sur le cloud.
L'intelligence de c7n est d'adresser ces points en se reposant sur un socle technique déjà là. Nous approchons donc un degré de maturation cloud native supplémentaire par rapport à une approche uniquement technique qui, bien que répondant au besoin de conformité, ne fournit pas l’interface de déclaration des règles de conformité la plus aboutie.
Cette solution reste à se parfaire, mais elle donne des éléments sur lesquels s’appuyer (notamment un DSL) pour envisager des solutions encore plus matures.
Plusieurs approches sont possibles pour adresser la conformité dans le Cloud. Les principaux fournisseurs proposent des services pour des besoins qui relèvent plus de l'opérationnel que du métier. Cette approche sera alors complétée voire remplacée par des processus chargés de vérifier le respect de règles métiers en s’appuyant sur des services internes au Cloud. C’est dans ce contexte que nous avons opposé une approche construction à une approche framework. Se basant sur un même socle technique de services managés, les deux se réclament d’une approche Cloud Native. La comparaison fait toutefois ressortir Cloud Custodian comme vainqueur par l’ajout de son DSL qui permet une expression directe sous la forme de règles, masquant la complexité technique d’une gestion de solution scalable. On produit directement la valeur des règles de compliance sans se soucier de l’architecture.
C’est en utilisant ce type de solution que la production de valeur sera libérée et contrôlée
Pour plus d'information vous pouvez visionnez la conférence que nous avons donné sur ce sujet au DevFest Nantes 2021.