Utiliser du contenu tiers en toute sécurité

Dernière partie d’une série en quatre volets sur la mise en place de votre stratégie AppSec pour Kubernetes.

Les parties précédentes sont disponibles ici :

• Sécuriser les conteneurs tout au long du SDLC

• Intégrer la sécurité dès le début, c’est une question de culture, pas seulement d’outils

• De la sécurité des images à celle des workloads

Dans notre réflexion sur la sécurité applicative pour Kubernetes, nous n’avons pas encore abordé les différences entre les applications développées en interne et celles de tiers.

Du point de vue de vos systèmes de production, il n’y a pas vraiment de différence entre les deux. Que vous ayez développé l’application ou qu’elle provienne d’un tiers, les similitudes sont nombreuses. Dans les deux cas, l’application a accès à certaines données de production et ses vulnérabilités peuvent entraîner la compromission de ces données ou des systèmes associés. Du point de vue classique des opérations, il est facile de traiter de la même façon les applications internes et tierces. Mais qu’en est-il lorsque certaines responsabilités opérationnelles sont transférées aux équipes de développement ?

Packaging des applications

Dans Kubernetes, il est courant d’installer des applications tierces à l’aide d’un outil comme Helm. Le dépôt Helm Charts contient la configuration de centaines d’applications, d’aerospike à zetcd, ce qui représente un gain de temps considérable. Les éditeurs de logiciels destinés aux consommateurs utilisent également de plus en plus Helm pour packager leurs applications. Un chart Helm contient la configuration nécessaire à l’installation de l’application, qui fait généralement référence à un ensemble d’images tierces. Plus récemment, nous avons vu apparaître des travaux sur les Cloud Native Application Bundles (CNAB), qui suivent un modèle similaire.

Examinons rapidement un exemple de chart Helm, en l’occurrence celui de Linkerd.

$ tree
.
├── Chart.yaml
├── README.md
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── config.yaml
│ ├── daemonset.yaml
│ ├── ingress.yaml
│ └── service.yaml
└── values.yaml

1 directory, 9 files.

Quels éléments du chart peuvent avoir une incidence sur la sécurité ? Le fichier Values.yaml contient des informations sur plusieurs images de conteneur, qui peuvent présenter des vulnérabilités :

image: buoyantio/linkerd:1.1.2
image: buoyantio/kubectl:v1.6.2

Le fichier values définit également des limites de ressources raisonnables

resources:
limits:
cpu: 500m
memory: 512M

Les templates, et en particulier le daemonset, contiennent une spécification de conteneur qui permet de configurer différentes propriétés de sécurité : exécution des conteneurs en tant que root, système de fichiers en lecture seule, demande des seules capacités nécessaires, définition d’une stratégie de sécurité des pods, etc.

Les applications tierces tout au long du SDLC

Comment ces considérations liées au packaging s’intègrent-elles à notre SDLC, et comment assurer la sécurité à chaque étape du cycle de vie ?

• En local : si vous utilisez des charts tiers, il se peut qu’aucune de vos équipes de développement ne travaille dessus en local.

• CI/CD : selon la manière dont vous installez les charts, vous pouvez y faire référence dans un fichier de configuration (Helmfile ou Terraform, par exemple), mais vous n’avez probablement pas de tests à ce stade, hormis éventuellement quelques tests de smoke.

• Registres : les charts Helm font généralement référence à des images hébergées dans des dépôts publics. Il est en général possible de remplacer ces images par des images internes, mais vous devrez mettre en place un processus pour maintenir vos copies internes à jour.

Pour une application autonome, le premier moment où vous pouvez vérifier la présence de vulnérabilités est aujourd’hui potentiellement son déploiement en production. Il existe donc un décalage entre la réalité — le transfert aux développeurs des décisions concernant le contenu tiers — et les capacités de nos outils à fournir rapidement des retours sur la sécurité de ces applications.

Types d’applications tierces

En simplifiant un peu, on peut répartir les applications tierces en deux catégories :

• Les applications autonomes qui apportent une valeur précise et distincte, comme WordPress ou Jenkins.

• Les dépendances directes d’une application développée en interne, comme Redis ou PostgreSQL.

La manière dont les applications tierces sont introduites dans nos environnements permet de comprendre l’utilité de cette distinction. Les applications autonomes préoccupent souvent davantage les équipes des opérations ou de la plateforme. Elles sont installées et gérées par une équipe centrale, qui les fournit en tant que service aux autres équipes de développement. Les dépendances directes relèvent plus souvent des équipes de développement individuelles. Pour sécuriser la chaîne d’approvisionnement logicielle tierce, nous devons tenir compte de ces deux perspectives.

Conclusion

Que pouvons-nous faire ? La réponse consiste à miser davantage sur l’automatisation et à concevoir des pipelines qui facilitent la validation et le test du contenu tiers le plus tôt possible. Ces pipelines doivent fonctionner aussi bien pour les applications autonomes (qui n’ont peut-être pas encore de pipeline) que pour tester les dépendances des applications existantes.

Pour résoudre ce problème, nous devons envisager l’ensemble de la chaîne d’approvisionnement logicielle. Il nous faut des outils locaux pour vérifier rapidement un chart Helm, un Operator ou un ensemble similaire de configurations et de références d’images. Il nous faut des pipelines CI/CD que nous pouvons mettre en place rapidement à la demande, afin de comprendre les risques liés à l’utilisation de contenu tiers lorsqu’il évolue. Il nous faut des pipelines rationalisés pour intégrer des images externes à notre environnement de confiance. Il serait également souhaitable que des normes voient le jour pour le partage de données fiables sur les vulnérabilités.

Il est possible d’utiliser des applications tierces en toute sécurité dans un environnement où les responsabilités sont rapidement transférées aux équipes de développement. Mais cela suppose de définir un processus adapté, puis d’en intégrer autant que possible les étapes au SDLC sécurisé.