Enregistrements DNS
Cette page répertorie les enregistrements DNS à créer pour un déploiement DuoKey sur site. Les enregistrements sont répartis en externes (résolvables par Microsoft 365 / les clients Office et les utilisateurs distants) et internes (résolvables à l'intérieur de votre réseau d'entreprise et du cluster).
Le nom d'hôte du point de terminaison de clé DKE doit être identique à trois endroits : l'enregistrement DNS, le SAN du certificat TLS et l'URL du point de terminaison DKE configurée sur l'étiquette de confidentialité Microsoft Purview. Une incompatibilité est la cause la plus courante des échecs DKE — voir Résolution des problèmes DKE.
Résolution split-horizon
Les clients Office doivent atteindre le point de terminaison DKE partout où le contenu protégé est ouvert — sur le réseau d'entreprise et, pour les utilisateurs distants, depuis Internet. Utilisez un DNS split-horizon afin que le même nom d'hôte se résolve vers le bon point d'entrée depuis chaque réseau, tandis que le nom d'hôte et le certificat TLS restent cohérents.
Enregistrements DNS externes
Créez ceux-ci dans votre zone DNS publique / externe (résolvable par les clients Office et les utilisateurs distants). Pointez-les vers votre VIP d'entrée public ou votre reverse proxy.
| Nom d'hôte (exemple) | Type | Cible | Objet |
|---|---|---|---|
dke.example.com | A / CNAME | VIP d'entrée public / reverse proxy | Point de terminaison de clé DKE — les clients Office récupèrent la clé ici (doit correspondre à l'URL de l'étiquette Purview) |
cockpit.example.com | A / CNAME | VIP d'entrée public | UI admin/utilisateur du Cockpit (uniquement si accédé de l'extérieur) |
cockpit-api.example.com | A / CNAME | VIP d'entrée public | API Cockpit (uniquement si accédée de l'extérieur) |
Si tous les utilisateurs ouvrent le contenu protégé par DKE uniquement depuis l'intérieur du réseau d'entreprise, le point de terminaison DKE peut être interne uniquement (aucun enregistrement public). Confirmez votre scénario d'accès distant avant de décider.
Enregistrements DNS internes
Créez ceux-ci dans votre zone DNS interne (réseau d'entreprise / cluster).
| Nom d'hôte (exemple) | Type | Cible | Objet |
|---|---|---|---|
*.apps.<cluster>.example.local | A / wildcard | VIP du routeur d'entrée | Routes d'application OpenShift (Cockpit, KMS, etc.) |
api.<cluster>.example.local | A | VIP LB du plan de contrôle | Serveur d'API OpenShift |
dke.example.com | A / CNAME | VIP LB interne | Point de terminaison DKE (vue interne du nom split-horizon) |
cockpit.example.local | A / CNAME | VIP du routeur d'entrée | UI Cockpit (accès interne) |
cockpit-api.example.local | A / CNAME | VIP du routeur d'entrée | API Cockpit (accès interne) |
dke-kms-api.example.local | A / CNAME | VIP LB interne | API DKE/KMS (accès interne) |
openbao.example.local | A | VIP / VM OpenBao | Moteur de secrets |
postgres.example.local | A | VIP / primaire PostgreSQL | Base de données |
gitlab.example.local | A / CNAME | VM GitLab | Source et registre (GitOps) |
argocd.example.local | A / CNAME | VIP du routeur d'entrée | Console GitOps (ArgoCD) |
harbor.example.local | A / CNAME | Harbor interne (miroir) | Registre d'images isolé (air-gapped) |
grafana.example.local | A / CNAME | VIP du routeur d'entrée | Tableaux de bord d'observabilité |
vmselect.example.local | A / CNAME | VIP du routeur d'entrée | Point de terminaison de requête VictoriaMetrics (facultatif, interne) |
vlogs.example.local | A / CNAME | VIP du routeur d'entrée | Point de terminaison de requête VictoriaLogs (facultatif, interne) |
Les composants qui communiquent entre eux à l'intérieur du cluster (Redis, le courtier de messages, vmagent/vmstorage/vminsert, Vector, les appels internes de service à service) utilisent la découverte de services Kubernetes — aucun enregistrement DNS externe/interne n'est requis. Ne créez des enregistrements que pour les points de terminaison que des humains ou des systèmes externes atteignent par leur nom.
Recommandations
- TTL : utilisez un TTL modéré (par exemple 300 à 3600 s). Abaissez-le temporairement avant un changement planifié de VIP/point de terminaison pour accélérer la propagation.
- VIP avec contrôle d'intégrité : pointez les enregistrements vers un VIP de répartiteur de charge qui effectue des contrôles d'intégrité sur les backends, pas vers un nœud unique.
- Certificats : assurez-vous que chaque nom d'hôte accessible de l'extérieur est un SAN sur son certificat TLS (voir Sécurité réseau → TLS).
- Gardez les noms stables : changer ultérieurement le nom d'hôte du point de terminaison DKE nécessite de mettre à jour l'étiquette Purview, le certificat et de revalider les clients.
Validation
# Resolve from a client network
nslookup dke.example.com
dig +short dke.example.com
# Confirm the DKE endpoint answers over TLS with the public key (JSON)
curl -I https://dke.example.com/<keyname>
Si la résolution ou le test du point de terminaison de clé échoue, consultez Résolution des problèmes DKE → Étape 1.