Pour les constructeurs de plateforme

Exécuter de nombreux locataires sur un seul plan de contrôle

Si vous hébergez des applications pour d'autres personnes — en tant que fournisseur d'hébergement, MSP ou agence qui maintient les systèmes de ses clients en fonctionnement — vous avez besoin de ce que les espaces de noms Kubernetes sont documentés pour ne pas être : une frontière de locataire que vous pouvez inscrire dans un contrat. Cette page explique en quoi consiste cette frontière ici, et cite le code pour chaque affirmation, de la même manière que le reste de ce site.

L'arithmétique du « faire ou acheter », montrée plutôt qu'affirmée

Chaque entreprise de plateforme arrive à la même bifurcation : construire la couche d'orchestration, ou en intégrer une. Nous ne allons pas vous citer une étude industrielle que nous ne pouvons pas vous montrer. Voici le seul chiffre qui est le nôtre, et d'où il vient.

Notre propre analyse tarifaire situe un ingénieur DevOps axé sur Kubernetes à 150 000 $ par an — c'est le chiffre que nous utilisons en interne lorsque nous comparons nos niveaux à l'alternative, et c'est une estimation que nous avons faite, pas une enquête salariale que nous avons menée. L'arithmétique qui en découle reste à faire avec vos propres chiffres :

Nous ne publions aucun prix partenaire sur cette page, et c'est délibéré : nous préférons vous dire que nous n'en avons pas fixé plutôt que d'inventer un chiffre pour remplir l'espace. Ce que coûte un accord de revente dépend du nombre de nœuds que vous exécutez et de la manière dont vous souhaitez être facturé, et c'est une conversation.

Multilocation, primitive par primitive

Six choses que vous auriez dû construire autrement. Chacune est un lien vers son emplacement dans la source, pour que vous puissiez vérifier plutôt que de croire.

Une hiérarchie de locataires, avec des sous-organisations

Un locataire peut avoir un parent. C'est un champ — ParentTenantID — et toute la hiérarchie en découle : créer une sous-organisation sous un parent, lister les enfants d'un parent, remonter la chaîne jusqu'à la racine, et refuser une opération qui traverserait une branche qu'elle ne devrait pas. Si vous revendez à des entreprises qui ont elles-mêmes des départements, des filiales ou des comptes clients, la structure existe déjà.

Facturation consolidée ou distincte, par sous-organisation

Chaque sous-organisation est créée soit consolidée, où le parent est facturé pour elle, soit séparée, où elle est facturée en son propre nom. C'est un champ validé sur le locataire, pas une convention dans une feuille de calcul, et consolidée est la valeur par défaut lorsque l'appelant ne le précise pas. C'est la différence entre la revente sous votre propre facture et l'introduction de clients qui paient directement &mdash ; et vous pouvez faire les deux, dans le même domaine, en même temps.

Quotas appliqués, non affichés

Un locataire porte des limites sur le nombre de déploiements, le nombre de conteneurs et le nombre de réplicas par déploiement qu'il peut avoir. Elles sont validées à l'entrée : une limite négative est un rejet, et un plafond de conteneurs inférieur au plafond de déploiements est également un rejet, car il décrit un état qui ne peut pas exister. Un niveau gratuit que vous ne pouvez pas appliquer est un niveau gratuit qui vous coûte de l'argent.

Un réseau Docker par locataire

Les réseaux de locataires sont nommés d'après l'identifiant propre du locataire, et un locataire en obtient un par défaut qu'il le demande ou non. Deux clients sur le même nœud ne partagent pas un segment réseau par accident, car il n'existe aucun chemin de code dans lequel ils en partagent un.

Sécurité au niveau des lignes dans la base de données, échec en mode fermé

La séparation des locataires dans le magasin d'audit est appliquée par Postgres lui-même, et non par une clause WHERE que quelqu'un devrait se souvenir d'écrire. La politique est fermée par défaut — une connexion sans locataire défini ne voit rien plutôt que tout — et il existe une suite de tests dédiée qui existe pour tenter de lire à travers la frontière et échouer.

Un maillage WireGuard par locataire, en trois topologies

Les nœuds de chaque locataire sont reliés par leur propre maillage chiffré, configuré en maillage complet, partiel ou en étoile. Le maillage en étoile exige que vous nommiez le nœud central — un maillage en étoile sans nœud central est refusé plutôt que rétrogradé silencieusement en autre chose. Pour un fournisseur disposant d'un site central et de nombreux accès client, cette troisième topologie est celle qui compte.

Pourquoi c'est une frontière et pas un espace de noms

Kubernetes documente que ses propres espaces de noms ne constituent pas une limite de sécurité. Ce n'est pas notre caractérisation du produit de quelqu'un d'autre ; c'est la leur, et c'est la raison pour laquelle une plateforme construite sur des espaces de noms finit par porter une seconde couche d'isolation que quelqu'un doit construire et maintenir fonctionnelle.

Ici, la limite est le locataire, et elle est constituée des six éléments ci-dessus à la fois : des réseaux séparés, des chemins Vault séparés, un espace clé-valeur séparé, des politiques de base de données qui échouent en mode fermé, et un maillage par locataire. Ce que nous pouvons offrir comme preuve est le nôtre : neuf suites de tests d'isolation dédiées dont le but est de tenter un accès inter-locataires et d'être refusées, et un audit de sécurité dont les 184 constatations et leur remédiation sont publiées intégralement plutôt que résumées.

La preuve, pas la promesse

Quatre pages sur ce site existent afin que les affirmations ci-dessus puissent être vérifiées plutôt que prises pour argent comptant :

• L'enregistrement d'audit — chaîné par hachage et activé par défaut, avec un vérificateur hors ligne autonome que vous remettez à un auditeur. C'est ce que vous montrez à l'équipe de conformité d'un locataire lorsqu'elle vous demande ce que vous pouvez prouver.
• L'audit de sécurité — 184 constats répartis sur six vagues validées, avec des identifiants de constats traçables jusqu'aux commentaires qui les ont clôturés.
• La preuve multi-cloud — une migration de conteneurs en direct et protégée entre deux nœuds cloud inscrits indépendamment, revérifiée par rapport au registre de nœuds du plan de contrôle.
• Le déploiement de référence — 123 conteneurs sous un seul plan de contrôle sur une seule machine à huit cœurs, incluant une pile de traitement de documents réglementés de 23 conteneurs et une plateforme non liée de 36 conteneurs à côté.

Là où vivent les données de vos locataires

Les nœuds appartiennent au locataire. Les charges de travail de vos clients, leurs volumes et leurs données résident sur des serveurs que vous ou eux contrôlez, dans la juridiction où se trouvent ces serveurs — le plan de contrôle contient l'état d'orchestration, pas les données applicatives. Pour un fournisseur vendant sur un marché avec des exigences de résidence, c'est l'arrangement utile : la réponse à “où sont mes données” est “où vous les avez mises,” et elle ne dépend pas de où nous sommes.

L'application de placement géographique — ancrage d'un déploiement à un pays ou une région au sein de votre propre flotte — est disponible et désactivée par défaut. Nous préférons le préciser plutôt que de laisser entendre qu'elle est activée.

Parlez-nous

Si vous construisez une plateforme par-dessus celle-ci, l'étape suivante est une conversation sur le nombre de nœuds, la forme de la facturation et ce que vos clients vous demanderont de prouver. Écrivez à sales@delta-telematics.ca.