Qu’est-ce que le DevSecOps?
Le DevSecOps est avant tout une philosophie culturelle. C’est une pratique permettant d’atteindre une excellence opérationnelle tout en ayant une efficacité structurelle. Le DevSecOps va apporter des avantages importants au sein des organisations :
- Plus de vélocité pour les équipes
- Des livraisons plus rapides et plus fréquentes
- Une fiabilité des déploiements et de l’application
- Une évolutivité améliorée et une collaboration entre les acteurs
- De la sécurité
Qu’est-ce que l’infrastructure as Code ?
Le cloud permet, dans la plupart des cas, de s’affranchir d’une infrastructure et de la gestion physique de cette dernière. Néanmoins, l’infrastructure existe toujours. Elle répond simplement à de nouvelles exigences et pratiques de la part des équipes. Une migration vers le cloud ne rendra donc pas vos équipes Ops obsolètes.
En effet, l’essor de l’Infrastructure as Code (IaC) permet de servir au mieux tous les acteurs de l’écosystème IT composant votre organisation. Souvent au cœur de la transformation DevOps, cette approche est ici non pas une commodité supplémentaire mais une obligation.
Outre une réorganisation pour prendre en compte ce changement de paradigme, un certain nombre de services et d’outils, souvent associés à certaines pratiques DevSecOps, sont nécessaires pour :
- L’intégration continue (CI)
- La livraison continue (CD)
- L’IaC
- Le monitoring
- La collaboration
L’outillage, souvent considéré comme une commodité, se retrouve ainsi au centre de l’implémentation DevSecOps dans les organisations. Il est donc nécessaire de prendre le temps de comprendre les offres des acteurs du marché et de s’intéresser à l’articulation des différents produits disponibles.
Comment les outils AWS répondent-ils aux exigences du DevSecOps ?
Voyons quels sont les outils fournis par AWS pour obtenir une stack DevSecOps pertinente et efficace.
Outils AWS pour l’Intégration Continue (CI)
L’intégration continue consiste à automatiser les phases de build, de test et de génération des livrables. De sorte qu’à chaque nouveau développement, les développeurs soient assurés qu’ils partent sur une base saine.
- CodeCommit est le premier maillon de la chaîne, c’est ici que l’on va stocker le code.
- CodeBuild met en œuvre les phases de build, de test et de génération des livrables. Cette phase peut être lancée à chaque commit dans CodeCommit par exemple.
- CodeArtifact est un dépôt d’artefacts. Il peut être utilisé pour stocker des résultats de CodeBuild, si le projet est une librairie par exemple. Imaginons que les développeurs d’un autre projet aient besoin de cette librairie à jour pour avancer. Ils auront ainsi une référence au dépôt d’artéfact dans leurs outils de gestion de dépendances.
- Elastic Container Registry (ECR) est un registre d’images Docker. Il peut être utilisé de la même façon que CodeArtifact, en imaginant que CodeBuild ait généré une (ou plusieurs) image Docker et que celle-ci soit utile à d’autres projets, ou à la phase de livraison.
Outils AWS pour la Livraison Continue (CD)
La livraison continue consiste à automatiser les phases de déploiement, à l’exception du déploiement en production qui reste un acte manuel.
- CodeDeploy permet de mettre en œuvre le déploiement ou la mise à jour d’une application sur des serveurs AWS ou on-premise.
- Code Pipeline fait le lien entre la partie CI et la partie CD. Un pipeline définit un workflow qui peut partir du commit et aller jusqu’au déploiement :
Quels outils AWS permettent de mettre en place une Infrastructure as Code ?
- CDK (Cloud Development Kit) peut être utilisé afin de mettre en place l’infrastructure qui fera tourner votre projet sous forme de code.
Compatible avec JavaScript, TypeScript, Python, Java, C#, et Go (en Developer Preview), il transformera votre langage préféré en configuration AWS gérée par CloudFormation. - CloudFormation peut être utilisé directement pour automatiser l’instanciation de ressources dans AWS
Voyons ensemble un exemple simple en TypeScript. Nous allons créer un secret managé par AWS qui ne pourra être lu que par un rôle IAM défini.
Pour commencer, AWS nous fournit une interface Stack pour nous aider dans la définition de notre infrastructure AWS :
export class InfraStack extends Stack {
constructor(scope: Construct, id: string, props?: StackProps) {
super(scope, id, props);
// définition de l’infrastructure ici
}
}
Tous les blocs de code ci-après seront au niveau du commentaire “définition de l’infrastructure ici”.
Créons le rôle IAM :
const secretRole = new iam.Role(this, 'MyRole', { assumedBy: new iam.AnyPrincipal() });
Celui-ci est stocké dans la variable secretRole qui pourra être utilisée pour la suite.
“MyRole” définit le nom que nous retrouverons dans CloudFormation.
“assumedBy” permet de restreindre qui peut assumer le rôle, ça peut être par exemple un WebIdentityPrincipal comme une identité web fédérée provisionnée par Facebook, Google, Cognito,… ou encore un ServicePrincipal comme Lambda ou EC2, un CanonicalUserPrincipal (un utilisateur AWS), etc.
Maintenant que nous avons le rôle, créons le secret :
const websiteAccessPassword = new sm.Secret(this, "WebsiteAccessPassword", {
generateSecretString: {
secretStringTemplate: "{}",
generateStringKey: "password"
}
});
D’abord, on initialise le secret qui sera appelé “WebsiteAccessPassword” dans CloudFormation. Cette initialisation demande à AWS de générer une chaîne de caractère qui correspondra au mot de passe contenu dans le secret.
“generateStringKey” génère la chaîne de caractère dans “password” et la clé “password” se trouve dans l’objet JSON vide “{}” donné par “secretStringTemplate”.
En d’autres termes, quand on ira chercher le secret (grâce, par exemple, à la commande CLI “aws secretsmanager get-secret-value »), celui-ci nous donnera un objet JSON formé de cette façon :
{
“password”: “leSecretGénéré”
}
Enfin, il faut donner à notre rôle les droits afin qu’il puisse lire notre secret :
websiteAccessPassword.grantRead(secretRole);
Petit bonus : on peut ajouter ce rôle à n’importe-quelle ressource qu’on aura créé. Par exemple, on peut vouloir accéder au secret à partir d’une instance EC2 qu’on aura créé aussi par CDK (ou qu’on aura référencé). Il suffit de lui donner le rôle secretRole :
const ec2Instance = new ec2.Instance(this, "ec2-instance", { “role”: secretRole, ... });
Pour finir avec CDK, une seule commande suffit à transformer notre code en infrastructure CloudFormation : “cdk deploy”
Une force de l’IaC, comme n’importe quel code source, est qu’il peut être maintenu avec de l’intégration et de la livraison continue. On peut alors déployer une infrastructure complète de la même façon qu’on le ferait avec les programmes qui seront exécutés sur cette même infrastructure.
Dans ce premier article, nous vous avons présenté les outils AWS permettant de livrer, déployer en continu et créer de l’Infrastructure as Code. Ces premières briques sont les fondations de votre infrastructure AWS. Cependant pour travailler au plus proche des pratiques DevSecOps et obtenir une stack consistante, d’autres briques complémentaires sont nécessaires : le monitoring et la collaboration. En attendant la prochaine série d’articles dédiés à ces sujets, découvrez notre offre AWS ici.
