DEV Community: Sam

ExternalDNS, Istio y AWS Route 53

Sam — Wed, 12 Jun 2019 07:53:50 +0000

En el anterior artículo dejaste configurado Istio y cert-manager para que trabajaran juntos sirviendo pods del service mesh sobre HTTPS. Menuda gozada, ¿verdad? Pero hasta que no configurasteis el registro DNS en vuestro proveedor, evidentemente, no se podía acceder. Hacer cosas a mano, ¿qué año es este? ¿2017?

En este artículo vamos a dejar instalado y configurado en el clúster la utilidad ExternalDNS, que se encargará de actualizar automáticamente nuestro proveedor de DNS basándose en los hosts configurados en los Gateways de Istio.

ExternalDNS es compatible con más de 15 proveedores de DNS, aunque solo dos de manera estable (GCloud y AWS Route 53), y es relativamente fácil de instalar y configurar en nuestro clúster. En esta parte, seguiremos con el ejemplo del artículo anterior, y vamos a integrarlo con AWS Route 53, para que cree automáticamente en Route 53 los hosts que activemos en los Gateways de Istio.

Configuración previa

Al igual que con cert-manager, y con todo en AWS, necesitamos crear una policy de IAM que otorgue al clúster o los pods que ejecuten ExternalDNS los permisos necesarios para trabajar con Route 53. En la propia documentación de ExternalDNS podemos encontrar el JSON que la define, pero básicamente es esta:

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Allow",
     "Action": ["route53:ChangeResourceRecordSets"],
     "Resource": ["arn:aws:route53:::hostedzone/*"]
   },
   {
     "Effect": "Allow",
     "Action": [
       "route53:ListHostedZones",
       "route53:ListResourceRecordSets"
     ],
     "Resource": ["*"]
   }
 ]
}

Creo que es importante señalar que la línea "Resource": ["arn:aws:route53:::hostedzone/*"] otorga permisos demasiado abiertos, y deberíamos modificarla indicando única y exclusivamente el ZONE_ID de las zonas que queremos que ExternalDNS gestione por nosotros.

Evidentemente, ya deberemos tener creada una zona DNS en AWS para que sea gestionada por ExternalDNS, porque esta utilidad no las crea.

Instalando y configurando ExternalDNS

Para instalar ExternalDNS tenemos disponible un chart de Helm, pero su fichero YAML de despliegue es tan sencillo, que nos vamos a limitar a copiarlo, y modificar los parámetros que integrarán ExternalDNS con Route 53. Si lo instaláis con el chart, podéis compartir la configuración a seguir en los comentarios.

Guardamos en un fichero local el YAML anterior, y pasamos a editar la parte del Deployment. En concreto, los valores para args:

[...]
        args:
        - --source=service
        - --source=ingress
        - --source=istio-gateway
        - --istio-ingress-gateway=custom-istio-namespace/custom-istio-ingressgateway # load balancer service to be used; can be specified multiple times. Omit to use the default (istio-system/istio-ingressgateway)
        - --domain-filter=external-dns-test.my-org.com # will make ExternalDNS see only the hosted zones matching provided domain, omit to process all available hosted zones
        - --provider=aws
        - --policy=upsert-only # would prevent ExternalDNS from deleting any records, omit to enable full synchronization
        - --aws-zone-type=public # only look at public hosted zones (valid values are public, private or no value for both)
        - --registry=txt
        - --txt-owner-id=my-identifier

--source: Indicamos a ExternalDNS qué tipo de recursos dentro del clúster debe analizar para actualizar el DNS. Si solo vamos a usar istio-gateway, podemos dejar únicamente este.
--istio-ingress-gateway: Este flag solo es obligatorio si hemos creado o usamos un ingressgateway distintio al que Istio crea por defecto (istio-ingressgateway). De ser así, eliminamos o comentamos esta línea.
--domain-filter: Restringimos la actualización de DNS de ExternalDNS a uno o varios dominios. Si eliminamos este flag, actualizará cualquier dominio que encuentre. Esto va muy relacionado con crear un política de IAM con los permisos necesarios.
--provider: En este caso, aws, ya que lo queremos integrar con Route 53.
--policy: Por defecto usa el valor sync, que elimina registros DNS cuando no los encuentra en ninguno de los source configurados. El valor upsert-only simplemente añade nuevos registros al DNS.
--aws-zone-type: Indicamos que la(s) zona(s) que ha de gestionar tienen carácter privado o público en Route 53.

Una vez que hayáis modificado estas opciones a vuestras necesidades, aplicáis al clúster. Podéis instalarlo en su propio namespace:

kubectl apply -n externaldns -f externaldns.yaml

Cuando el pod esté en estado Running, si tenemos algún Gateway de Istio configurado, ExternalDNS empezará a crear registros DNS en Route 53. En caso de no tener aún nada, aplicamos nuestro Gateway y VirtualService, y en unos pocos minutos veremos en los logs del pod cómo empieza a añadir los registros:

time="2019-06-10T15:51:33Z" level=info msg="Desired change: CREATE nginx.example.com A"
time="2019-06-10T15:51:33Z" level=info msg="Desired change: CREATE nginx.example.com TXT"
time="2019-06-10T15:51:36Z" level=info msg="2 record(s) in zone example.com. were successfully updated"

Con estas opciones conseguiremos despreocuparnos de la configuración DNS, que ExternalDNS se encargará de gestionar por nosotros. Esta configuración puede sernos tremendamente útil para presentar en endpoints temporales, mediante Integración Continua, una nueva feature de nuestra web y, combinándolo con cert-manager, en un perfecto HTTPS.

Istio, SDS y cert-manager

Sam — Sat, 08 Jun 2019 15:26:36 +0000

Si has llegado hasta aquí, ya sabes qué es Kubernetes. Incluso puede que hayas levantado tu propio clúster en local, usando Minikube. O hasta en una de los cientos de nubes públicas y privadas que ofrecen un servicio de Kubernetes auto gestionado. ¡Será por opciones!

En esta serie de posts vamos a ver cómo instalar/actualizar Istio para hacerlo funcionar conjuntamente con cert-manager, que nos proporcionará certificados gratuitos mediante Let's Encrypt, y ExternalDNS, que actualizará nuestros DNS cada vez que añadamos una entrada a un Gateway de Istio.

¿Qué es SDS? ¿y mTLS?

SDS son las siglas en inglés de Secret Discovery Service. Antes de Istio 1.1, las claves privadas y certificados generados por Istio eran manejados por Citadel, y montados como volúmenes en los pods sidecar de los pods. Esto tenía ciertas desventajas:

Al renovar un certificado, Istio reinicia en caliente el sidecar de Envoy, provocando pérdidas de rendimiento.
Las claves privadas se guardaban en secretos de Kubernetes, lo cual tiene ciertos riesgos.

Resumiendo, SDS soluciona estos problemas generando una clave privada y CSR en Citadel (que funciona como DaemonSet, es decir, en todos los nodos de Kubernetes) mediante token JWT enviado por el sidecar de Envoy. Citadel comprueba el token y, si todo es correcto, genera y envía el certificado y la clave privada al sidecar.

Podéis encontrar más detalles de cómo funciona en el blog de Istio, y en la documentación de Envoy.

Por otra parte, mTLS (mutual TLS), configura todos los pods del clúster para que hablen entre ellos usando TLS, por lo que todas las comunicaciones entre microservicios estarán cifradas y los componentes de Istio se encargarán de gestionar los certificados.

Instalando Istio con mTLS y SDS

En este artículo, partimos de un clúster vacío. Si ya tenemos un clúster funcionando sin Istio, tenemos que tener en cuenta que, para que Istio inyecte el pod sidecar en un namespace, tendremos que etiquetar ese namespace con la siguiente label:

kubectl label namespace production istio-injection=enabled

Una vez aplicado, tendremos que levantar nuevos pods para que Istio inyecte el sidecar, y eliminar los antiguos.

Para instalar Istio, usaremos Helm. Nos descargamos la última versión de Istio, y la descomprimimos.

Instalamos primeros los CRDs de Istio en el clúster. Puedes omitir este paso si ya lo tenías instalado:

helm install --name istio-init --namespace istio-system istio-1.1.7/install/kubernetes/helm/istio-init

Crearemos un fichero de values parecido a values-istio-sds-auth.yaml que viene en el tar, con ciertas modificaciones que explico comentadas en el fichero:

$ cat values-istio-sds-auth.yaml
global:
  controlPlaneSecurityEnabled: false

  mtls:
    enabled: true

  sds:
    enabled: true
    udsPath: "unix:/var/run/sds/uds_path"
    useNormalJwt: true

nodeagent:
  enabled: true
  image: node-agent-k8s
  env:
    CA_PROVIDER: "Citadel"
    CA_ADDR: "istio-citadel:8060"
    VALID_TOKEN: true
# Fin del fichero original

# Valores añadidos manualmente
# En la sección anterior, el parámetro global.sds.enabled=true activa SDS únicamente en los pods sidecar de Istio.
# En esta sección, configuramos el ingressgateway para que reciba los certificados con el mismo método.
gateways:
  istio-ingressgateway:
    enabled: true
    sds:
      enabled: true

# Esta sección inferior soluciona los livenessProbe y readinessProbe de Kubernetes configurados mediante httpGet,
# que fallan por el sidecar de Istio.
sidecarInjectorWebhook:
  enabled: true
  rewriteAppHTTPProbe: true

Instalamos con el comando:

helm install \
  --name istio \
  --namespace istio-system \
  istio-1.1.7/install/kubernetes/helm/istio \
  --values values.yaml # values.yaml es nuestro fichero modificado

Tras unos minutos de tensión, deberías tener Istio funcionando en tu clúster:

$ kubectl get pods -n istio-system
NAME                                       READY   STATUS    RESTARTS   AGE
istio-citadel-7f447d4d4b-f8lzt             1/1     Running   0          1m
istio-galley-84749d54b7-7sngg              1/1     Running   0          1m
istio-ingressgateway-57c97bb7f6-8294g      2/2     Running   0          1m
istio-nodeagent-nrl7v                      1/1     Running   0          1m
istio-nodeagent-vkchb                      1/1     Running   0          1m
istio-pilot-76899788b6-xcw7t               2/2     Running   0          1m
istio-policy-578bcb878f-ddwh7              2/2     Running   2          1m
istio-sidecar-injector-6895997989-5qsnn    1/1     Running   0          1m
istio-telemetry-5448cbd995-jcpdg           2/2     Running   2          1m

¡Enhorabuena! Ya tienes Istio funcionando. Tómate un café, te lo has ganado.

Instalando cert-manager

Debido a un bug con cert-manager y la última versión de Helm, vamos a instalar el primero templatizando el chart de cert-manager.

missing "caBundle" in ValidatingWebhookConfiguration when installing with helm #1702

andrei-dascalu posted on May 19, 2019

Describe the bug: When installing using helm as per documentation helm install --name cert-manager --namespace cert-manager --version v0.7.2 jetstack/cert-manager (step-by-step following the documentation on a clean new cluster running v1.12.7 in cluster (AKS) and helm v2.14.0)

The result is: Error: validation failed: error validating "": error validating data: [ValidationError(ValidatingWebhookConfiguration.webhooks[0].clientConfig): missing required field "caBundle" in io.k8s.api.admissionregistration.v1beta1.WebhookClientConfig, ValidationError(ValidatingWebhookConfiguration.webhooks[1].clientConfig): missing required field "caBundle" in io.k8s.api.admissionregistration.v1beta1.WebhookClientConfig, ValidationError(ValidatingWebhookConfiguration.webhooks[2].clientConfig): missing required field "caBundle" in io.k8s.api.admissionregistration.v1beta1.WebhookClientConfig]

Expected behaviour: Cert-manager is installed

Steps to reproduce the bug: Steps as per https://docs.cert-manager.io/en/latest/getting-started/install.html#installing-with-helm

Anything else we need to know?:

Environment details::

Kubernetes version (e.g. v1.12.7):
Cloud-provider/provisioner (e.g. GKE, kops AWS, etc): AKS
cert-manager version (e.g. v0.4.0): 0.7.2
Install method (e.g. helm or static manifests): helm

/kind bug

View on GitHub

Descargamos el chart de cert-manager y descomprimimos:

helm fetch --untar stable/cert-manager

Como no tenemos que modificar ningún parámetro del values.yaml para instalarlo en el clúster, templatizamos y aplicamos:

helm template . --name cert-manager --namespace istio-system > cert-manager.yaml
kubectl apply --file cert-manager.yaml

IMPORTANTE: Como veis, instalamos cert-manager en el namespace de Istio, istio-system. Esto es un requisito, ya que para que funcione SDS, los secretos que contienen los certificados deben encontrarse en el mismo namespace en el que está Istio. Los Gateways y VirtualServices de Istio podrán estar en su namespace correspondiente.

NOTA: en el propio chart de Istio podemos indicar una opción para instalar cert-manager. En este artículo lo instalamos de manera independiente para poder manejarlo independientemente de la instalación de Istio.

Una vez esté instalado cert-manager en el namespace de Istio, tendremos que configurar un emisor de certificados. Vamos a configurarlo para que use Let's Encrypt, y confirme los certificados resolviendo un DNS01 Challenge, que nos permitirá generar certificados de tipo wildcard, es decir, *.example.com.

En este caso, usamos AWS Route 53 como DNS, por lo que el clúster o pods necesitarán unos permisos específicos de IAM para trabajar con este servicio de AWS.

Generamos el fichero clusterissuer.yaml con este contenido:

# clusterissuer.yaml
apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: letsencrypt
  labels:
    app: certmanager
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: <EMAIL> # Sustituir por un correo válido
    privateKeySecretRef:
      name: letsencrypt # Secreto donde cert-manager guardará datos
    # Configuramos el proveedor para Route 53. En este caso no se indican credenciales de AWS,
    # dado que los pods y/o nodos de k8s tienen asignado un rol de IAM con permisos.
    dns01:
      providers:
      - name: route53
        route53:
          region: eu-west-1
#          # Descomenta esto, y modifica acorde,
#          # para usar unas credenciales de IAM que otorguen los permisos
#          accessKeyID: AKIAIOSFODNN7EXAMPLE
#          secretAccessKeySecretRef:
#            name: prod-route53-credentials-secret
#            key: secret-access-key

Y aplicamos:

kubectl apply -f clusterissuer.yaml

Tendremos disponible, a nivel de clúster, la creación de certificados usando los certificados de Let's Encrypt. Pero primero tenemos que definir un certificado, para que cert-manager se encargue de solicitarlo automáticamente:

# wildcard.example.com.yaml
apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: wildcard.example.com
  namespace: istio-system # Recordad: es necesario que los certificados estén en el namespace de Istio
spec:
  secretName: wildcard.example.com
  issuerRef:
    kind: ClusterIssuer
    name: letsencrypt
  commonName: "*.example.com"
  dnsNames:
  - example.com
  acme:
    config:
    - dns01:
        provider: route53
      domains:
        - '*.example.com'
        - example.com

kubectl apply -f wildcard.example.com.yaml

Si todo está correctamente configurado, en unos minutos tendremos disponible el certificado:

$ kubectl describe certificates wildcard.example.com
[...]
Status:
  Conditions:
    Last Transition Time:  2019-05-30T09:27:56Z
    Message:               Certificate is up to date and has not expired
    Reason:                Ready
    Status:                True
    Type:                  Ready
  Not After:               2019-08-28T08:27:54Z
[...]

¡Excelente! Ya tenemos el certificado. Pero, ¿cómo hacemos para que Istio envie el tráfico a nuestros pods, y se encargue de configurar el certificado? Para ello, hacemos uso de los Gateways y VirtualServices de Istio.

Configurando Gateways y VirtualServices

Esta es fácil. Simplemente tendremos que generar un Gateway de Istio donde configuramos el DNS y el certificado, y un VirtualService que envíe el tráfico según el host al servicio correspondiente de Kubernetes. Para este ejemplo, usaremos el servicio nginx:

# route.yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: example-gateway
  namespace: production # Podemos crear los Gateways en el namespace que queramos
spec:
  selector:
    istio: ingressgateway # Gateway de Istio por donde entra el tráfico al service mesh
  servers:
  # Configuramos el puerto 80 para que Istio haga la redirección a HTTPS
  - port:
      number: 80
      name: http-redirect
      protocol: HTTP
    hosts:
    - "nginx.example.com"
    tls:
      httpsRedirect: true
  - port:
      number: 443
      name: nginx-https
      protocol: HTTPS
    tls:
      # En credentialName, indicamos el nombre del secreto configurado
      # en el Certificate anteriormente creado
      credentialName: wildcard.example.com
      mode: SIMPLE
      # En las dos siguientes claves, indicamos a Istio que use el sistema SDS
      # para obtener el certificado
      privateKey: sds
      serverCertificate: sds
    hosts:
      - "nginx.example.com"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginx-route
  namespace: production
spec:
  gateways:
    - example-gateway # OJO, hace referencia al gateway creado más arriba
  hosts:
    - nginx.example.com
  http:
    - match:
      - uri:
          prefix: "/"
      route:
      - destination:
          host: nginx.production.svc.cluster.local
          port:
            number: 443

Aplicamos este fichero con kubectl apply -f routes.yaml, et voilà! Istio inyectará automáticamente el certificado configurado (en este caso, el wildcard) cuando entremos al DNS del servicio, nginx.example.com.

¿Pero no íbamos a configurar ExternalDNS para que generara las entradas automáticamente en Route 53? De momento, hazlo a mano, y en el próximo post vemos cómo integrar ExternalDNS con Istio, y Route 53.

Prometo que será corto.