Chart de Helm para Kubernetes
Si tienes un clúster de Kubernetes, el chart de Helm mta-sts sirve tu política MTA-STS desde tu propia infraestructura. Lo mantiene DMARC Examiner, es código abierto (licencia MIT) y funciona en cualquier plan, también en Free.
Si no quieres mantener nada, usa el MTA-STS alojado.
Qué hace
- Varios dominios. Una sola instalación sirve
mta-sts.<dominio>para cada dominio de la lista, cada uno con su propia política. idautomático. Eliddel registro_mta-stssale del contenido de la política: cambia solo cuando cambia la política.- Registros DNS como código. Con external-dns, crea los registros TXT
_mta-stsy_smtp._tls(TLS-RPT). Sin external-dns, te muestra los registros que tienes que crear. - TLS. Anota el Ingress para cert-manager (
ClusterIssueroIssuer). - Seguro por defecto. nginx sin root, sistema de ficheros de solo lectura y sin capacidades.
- Validación. Rechaza modos no válidos, un
max_agefuera de rango, MX mal escritos y direcciones TLS-RPT mal formadas antes de instalar nada. helm test. Descarga cada política a través del Service y comprueba que un host desconocido recibe un 404.
Requisitos
- Kubernetes 1.25 o superior y Helm 3.8 o superior.
- Un Ingress controller accesible desde internet en el puerto 443.
- Un certificado de confianza pública para cada
mta-sts.<dominio>. cert-manager con Let's Encrypt sirve. mta-sts.<dominio>tiene que resolver a tu Ingress.- Opcional: external-dns con la fuente
crd, para gestionar los registros TXT.
Instalar
helm install mta-sts oci://ghcr.io/dmarc-examiner/charts/mta-sts \
--namespace mta-sts --create-namespace -f values.yamlUn dominio con Google Workspace
Pon tu dirección de informes de DMARC Examiner en tlsRpt.rua. La encuentras en la pestaña Registros DNS del dominio, en Registro TLS-RPT.
domains:
- name: example.com
policy:
mode: testing
mx:
- aspmx.l.google.com
- "*.aspmx.l.google.com"
tlsRpt:
rua:
- mailto:<tu-dirección-de-informes>
ingress:
className: nginx
certManager:
clusterIssuer: letsencryptCon Microsoft 365, el MX es *.mail.protection.outlook.com.
Varios dominios con políticas distintas
Cada dominio puede cambiar mode, maxAge, mx y tlsRptRua. Lo que no cambie lo toma de policy y tlsRpt.
domains:
- name: example.com
- name: example.org
mode: enforce
mx:
- mx1.example.org
- mx2.example.org
- name: legacy.example.net
mode: none
policy:
mode: testing
mx:
- mx.example.comEn tlsRpt.rua, {domain} se sustituye por el nombre de cada dominio.
Registros DNS con external-dns
externalDns:
enabled: true
labels:
dns: publicEl chart crea un DNSEndpoint por dominio con estos registros:
| Nombre | Tipo | Valor |
|---|---|---|
_mta-sts.example.com |
TXT | v=STSv1; id=<20 caracteres hexadecimales> |
_smtp._tls.example.com |
TXT | v=TLSRPTv1; rua=mailto:<tu-dirección-de-informes> |
external-dns necesita --source=crd y, si pones etiquetas, el --label-filter correspondiente. El registro A o CNAME de mta-sts.<dominio> sale del Ingress, como siempre.
Sin external-dns, helm install y helm upgrade muestran en las notas los registros exactos que tienes que crear.
El id de la política
El chart calcula id = primeros 20 caracteres hexadecimales de sha256(fichero de política). Un helm upgrade que no toca la política mantiene el id. Si la cambia, el id cambia solo. Con external-dns el registro TXT se actualiza; sin él, copia el valor nuevo de las notas.
Despliegue y retirada
| Paso | Valores |
|---|---|
| Empezar | mode: testing y tlsRpt.rua |
| Pasar a enforce | mode: enforce, tras una o dos semanas de informes TLS sin fallos |
| Cambiar de MX | Añade los MX nuevos a mx antes de cambiar el DNS |
| Retirar | mode: none durante un maxAge entero; después, helm uninstall |
Los motivos de cada paso están en Qué es MTA-STS.
Comprobar
helm test mta-sts -n mta-sts
curl -s https://mta-sts.example.com/.well-known/mta-sts.txt
dig +short TXT _mta-sts.example.comEn DMARC Examiner, la tarjeta MTA-STS del dominio muestra el modo publicado y la pestaña TLS los informes de los remitentes.
La lista completa de valores está en el README del chart.