Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

452
Views
Genere un certificado comodín en el clúster de Kubernetes con DigitalOcean para mi Nginx-Ingress

Seguí esta guía de DigitalOcean https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes y encontré algo bastante extraño. Cuando en los nombres de host configuro un comodín, luego letsencrypt falla al emitir un nuevo certificado. Mientras que cuando solo configuro subdominios definidos, funciona perfectamente.

Esta es mi configuración "funcional" para el dominio y su API (y esta funciona perfectamente):

 apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: my-ingress annotations: cert-manager.io/cluster-issuer: "letsencrypt-staging" spec: tls: - hosts: - example.com - api.example.com secretName: my-tls rules: - host: example.com http: paths: - backend: serviceName: example-frontend servicePort: 80 - host: api.example.com http: paths: - backend: serviceName: example-api servicePort: 80

Y este es, en cambio, el certificado comodín que estoy tratando de emitir, pero que no deja el mensaje "Emitiendo".

 apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: my-ingress annotations: cert-manager.io/cluster-issuer: "letsencrypt-staging" spec: tls: - hosts: - example.com - *.example.com secretName: my-tls rules: - host: example.com http: paths: - backend: serviceName: example-frontend servicePort: 80 - host: api.example.com http: paths: - backend: serviceName: example-api servicePort: 80

La única diferencia es la segunda línea de los anfitriones. ¿Hay una solución trivial bien conocida que no conozco? Soy nuevo en Kubernetes, pero no en DevOps.

over 4 years ago · Santiago Trujillo
2 answers
Answer question

0

La generación de un certificado comodín con cert-manager ( letsencrypt ) requiere el uso del desafío DNS-01 en lugar del HTTP-01 se usa en el enlace de la pregunta :

¿Let's Encrypt emite certificados comodín?

Sí. La emisión de comodines debe realizarse a través de ACMEv2 utilizando el desafío DNS-01. Consulte esta publicación para obtener más información técnica.

Hay una documentación sobre cómo generar el certificado wildcard con cert-manager :

  • Cert-manager.io: Documentos: Configuración: ACME: DNS-01

Desde la perspectiva de DigialOcean, existe una guía específicamente dirigida a ello:

Este proveedor utiliza un recurso Secret de Kubernetes para funcionar. En el siguiente ejemplo, el Secret deberá llamarse digitalocean-dns y tener un access-token con el token en él. Por ejemplo:

 apiVersion: v1 kind: Secret metadata: name: digitalocean-dns namespace: cert-manager data: # insert your DO access token here access-token: "base64 encoded access-token here"

El token de acceso debe tener acceso de escritura.

Para crear un token de acceso personal, consulte la documentación de DigitalOcean .

Práctico enlace directo: https://cloud.digitalocean.com/account/api/tokens/new

Para codificar su token de acceso en base64, puede usar lo siguiente

 echo -n 'your-access-token' | base64 -w 0
 apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: example-issuer spec: acme: ... solvers: - dns01: digitalocean: tokenSecretRef: name: digitalocean-dns key: access-token

-- Cert-manager.io: Documentos: Configuración: ACME: DNS-01: Digitalocean


Creo que estos recursos adicionales también podrían ayudar:

  • Stackoverflow.com: Preguntas: Certificado Wilcard SSL con redirección de subdominio en Kubernetes
  • Itnext.io: uso de certificados comodín con cert-manager en Kubernetes
over 4 years ago · Santiago Trujillo Report

0

El certificado comodín requiere el método DNS-01

Nota : es posible que deba agregar primero el registro CAA en su DNS.

El registro CAA se puede agregar a la zona DNS

ejemplo :

 Type Value devops.in CAA 0 issuewild "letsencrypt.org"

obtener detalles de: https://sslmate.com/caa/

Primero, debe crear el secreto para almacenar la access key usando el comando

 kubectl create secret generic route53-secret --from-literal=secret-access-key="skjdflk4598sf/dkfj490jdfg/dlfjk59lkj"

Aquí compartiendo el ejemplo issuer.yaml

 apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: letsencrypt-prod spec: acme: email: test123@gmail.com server: https://acme-v02.api.letsencrypt.org/directory privateKeySecretRef: name: letsencrypt-prod solvers: - selector: dnsZones: - "devops.in" dns01: route53: region: us-east-1 hostedZoneID: Z2152140EXAMPLE accessKeyID: AKIA5A5D7EXAMPLE secretAccessKeySecretRef: name: route53-secret key: secret-access-key --- apiVersion: cert-manager.io/v1alpha2 kind: Certificate metadata: name: le-crt spec: secretName: tls-secret issuerRef: kind: Issuer name: letsencrypt-prod commonName: "*.devops.in" dnsNames: - "*.devops.in"

Además, asegúrese de que su usuario tenga los permisos necesarios para administrar Route53

 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "route53:GetChange", "Resource": "arn:aws:route53:::change/*" }, { "Effect": "Allow", "Action": "route53:ChangeResourceRecordSets", "Resource": "arn:aws:route53:::hostedzone/*" }, { "Effect": "Allow", "Action": "route53:ListHostedZonesByName", "Resource": "*" } ] }
over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!