Cert manager

cert-manager on varmenteiden hallintaohjain, joka myöntää ja uusii TLS-varmenteet puolestasi. Sen sijaan, että pyytäisit varmenteen käsin ja muistaisit vaihtaa sen ennen vanhenemista, kuvaat haluamasi varmenteen API-objektina, ja cert-manager pitää Kubernetesin Secret-objektin ajan tasalla voimassa olevalla varmenteella ja sen yksityisavaimella. Rahti-palvelussa cert-manager tarjotaan hallinnoituna komponenttina, joten sinun ei tarvitse asentaa tai ylläpitää ohjainta itse.

Cert manager

Koska tuloksena on tavallinen Secret, mikä tahansa Rahti-projektissasi ajettava komponentti voi käyttää sitä: verkkopalvelin kuten NGINX tai Apache HTTP Server, tietokanta kuten PostgreSQL, välimuisti kuten Redis, viestinvälityspalvelu, oma sovelluksesi tai Ingress, joka julkaisee sovelluksen internetiin. Varmenne voi tulla miltä tahansa ACME-protokollaa käyttävältä varmentajalta, omalta varmentajaltasi tai itseallekirjoitetusta avaimesta.

Miten cert-manager toimii

Mukana on kolme objektia:

Issuer kuvaa, mistä varmenteet tulevat: ACME-varmentajalta, omalta varmentajaltasi tai itseallekirjoitetusta avaimesta. Issuer on nimiavaruuskohtainen, joten se toimii siinä Rahti-projektissa, jossa se luodaan.
Certificate kuvaa haluamasi varmenteen: mitä isäntänimiä se kattaa, kuinka kauan se on voimassa ja minkä Secret-objektin nimellä se tallennetaan.
Tuloksena syntyvä Secret sisältää myönnetyn varmenteen kentässä tls.crt ja yksityisavaimen kentässä tls.key. Omalla varmentajallasi allekirjoitetuissa varmenteissa CA-varmenne on lisäksi kentässä ca.crt.

Kun Certificate luodaan, cert-manager ottaa yhteyttä myöntäjään, suorittaa kaikki myöntäjän vaatimat varmennukset ja kirjoittaa tuloksen Secret-objektiin. Ennen varmenteen vanhenemista cert-manager toistaa prosessin ja päivittää saman Secret-objektin, joten uusiminen ei vaadi sinulta toimenpiteitä. Työkuormat, jotka lukevat varmenteen liitetystä taltiosta, näkevät uuden tiedoston automaattisesti, vaikka monet palvelimet täytyy ladata uudelleen tai käynnistää uudelleen ennen kuin ne käyttävät sitä.

Issuer, ei ClusterIssuer

cert-managerissa on myös klusterikohtainen ClusterIssuer-objekti. Sen luominen vaatii klusterin ylläpitäjän oikeudet, joita Rahti-käyttäjillä ei ole, joten luo aina Issuer omaan Rahti-projektiisi.

ACME-varmenteet

Automatic Certificate Management Environment (ACME) -protokolla automatisoi varmentajan ja palvelimesi välisen vuorovaikutuksen. cert-manager toimii minkä tahansa ACME:tä tukevan varmentajan kanssa, ja niiden välillä vaihtaminen on useimmiten vain server-kentän osoittamista toiseen hakemisto-URL-osoitteeseen. Jos organisaatiosi, instituutiosi tai kaupallinen varmennepalveluntarjoajasi tarjoaa ACME-päätepisteen, käytä sitä: säilytät nykyisen tilisi, nykyiset varmennussääntösi ja kaikki varmenneprofiilit, joihin jo luotat.

Alla oleva esimerkki käyttää Let's Encryptiä, voittoa tavoittelematonta varmentajaa, joka myöntää ilmaisia varmenteita ACME:n kautta, koska se ei vaadi tilin ennakkoasetuksia.

Esivaatimukset

oc-komentorivityökalu on asennettu, ja olet kirjautunut oikeaan Rahti-projektiin (oc project <project_name>).
Verkkotunnus, jonka julkinen DNS-tietue osoittaa Rahtiin, kuten on kuvattu sivulla Mukautetut verkkotunnukset. ACME-varmentajan täytyy varmistaa, että hallitset verkkotunnusta, ja alla olevassa esimerkissä ACME käyttää HTTP-01:tä, joka varmistaa verkkosivuston hallinnan sijoittamalla tietyn tiedoston tiettyyn osoitteeseen kyseisellä sivustolla.

1. Luo Issuer

Tallenna seuraava tiedostoon issuer.yaml. Korvaa <EMAIL> omalla osoitteellasi, jota varmentaja käyttää tiliäsi varten ja vanhenemisvaroituksiin:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: acme-issuer
spec:
  acme:
    email: <EMAIL>
    # The directory URL of your ACME certificate authority.
    # This example uses Let's Encrypt.
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      # Secret where the account's private key is stored.
      name: acme-account-key
      key: tls.key
    # A single challenge solver, HTTP01 through the Rahti router
    solvers:
    - http01:
        ingress:
          ingressClassName: openshift-default

oc apply -f issuer.yaml

http01-ratkaisija saa cert-managerin julkaisemaan väliaikaisen varmennus-URL-osoitteen verkkotunnuksessasi. Asetuksella ingressClassName: openshift-default tämä URL-osoite julkaistaan Rahti-reitittimen kautta, minkä vuoksi verkkotunnuksen täytyy jo osoittaa Rahtiin.

Oman ACME-tilin käyttäminen

Jos sinulla on jo ACME-tili palveluntarjoajalla, luo privateKeySecretRef-kentässä nimetty Secret itse olemassa olevasta tiliavaimestasi, jolloin cert-manager käyttää kyseistä tiliä uuden rekisteröinnin sijaan:

oc create secret generic acme-account-key --from-file=tls.key=account.key

Monet kaupalliset varmentajat vaativat lisäksi External Account Bindingin, joka liittää ACME-tilin tilaukseesi. Tallenna heiltä saamasi HMAC-avain Secret-objektiin ja viittaa siihen yhdessä avaintunnisteen kanssa:

oc create secret generic acme-eab-hmac --from-literal=secret='<EAB_HMAC_KEY>'

Issuerin pitäisi näyttää seuraavalta, kun lisäät ACME-tilisi tunnistetiedot.

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: own-acme-issuer
spec:
spec:
  acme:
    email: <EMAIL>
    server: <ACME_DIRECTORY_URL>
    externalAccountBinding:
      keyID: <EAB_KEY_ID>
      keySecretRef:
        name: acme-eab-hmac  # -> The secret name from the above command
        key: secret
    privateKeySecretRef:
      name: acme-account-key
      key: tls.key
    solvers:
    - http01:
        ingress:
          ingressClassName: openshift-default

Testaa ensin testiympäristöä vasten

Varmentajat asettavat rajoituksia verkkotunnukselle myönnettävien varmenteiden määrälle, ja väärin määritetty ratkaisin voi kuluttaa tämän kiintiön nopeasti. Useimmat palveluntarjoajat tarjoavat testiympäristön päätepisteen testausta varten; Let's Encryptillä se on:

server: https://acme-staging-v02.api.letsencrypt.org/directory

Testiympäristön varmenteisiin selaimet eivät luota, mutta ne myönnetään huomattavasti väljemmillä rajoilla. Vaihda tuotanto-URL-osoitteeseen, kun varmenne on myönnetty onnistuneesti.

2. Luo Certificate

Tallenna seuraava tiedostoon certificate.yaml ja korvaa molemmat <HOSTNAME>-esiintymät verkkotunnuksella, jolle haluat varmenteen:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-app
spec:
  secretName: hostname-tls
  duration: 2160h # 90d
  renewBefore: 360h # 15d
  issuerRef:
    name: acme-issuer
    kind: Issuer
  commonName: <HOSTNAME>
  dnsNames:
    - <HOSTNAME>

oc apply -f certificate.yaml

Näillä arvoilla varmenne on voimassa 90 päivää, ja cert-manager uusii sen 15 päivää ennen vanhenemista. Säädä duration- ja renewBefore-arvot sen mukaan, mitä varmentajasi sallii. Kun myöntäminen onnistuu, projektiisi ilmestyy Secret nimeltä hostname-tls, jossa ovat merkinnät tls.crt ja tls.key.

Varmenteen käyttäminen sovelluksessa

Liitä Secret taltiona ja osoita palvelimesi kahteen tiedostoon. Seuraava Deployment tuo ne saataville polkuun /etc/tls:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: <your_image>
        volumeMounts:
        - name: tls
          mountPath: /etc/tls
          readOnly: true
      volumes:
      - name: tls
        secret:
          secretName: hostname-tls
          defaultMode: 0440

Asetettava määritysvalinta riippuu ohjelmistosta:

NGINX: ssl_certificate /etc/tls/tls.crt; ja ssl_certificate_key /etc/tls/tls.key;
Apache HTTP Server: SSLCertificateFile /etc/tls/tls.crt ja SSLCertificateKeyFile /etc/tls/tls.key
Redis: --tls-cert-file /etc/tls/tls.crt --tls-key-file /etc/tls/tls.key
PostgreSQL: ssl_cert_file = '/etc/tls/tls.crt' ja ssl_key_file = '/etc/tls/tls.key'

Yksityisavaintiedoston käyttöoikeudet

Jotkin palvelimet, PostgreSQL niiden joukossa, kieltäytyvät käynnistymästä, jos yksityisavain on luettavissa muille kuin sen omistajalle ja ryhmälle. Yllä oleva asetus defaultMode: 0440 pitää liitetyt tiedostot muiden käyttäjien ulottumattomissa. Huomaa myös, että liitetty Secret päivitetään paikallaan, kun cert-manager uusii varmenteen, mutta useimmat palvelimet lukevat sen vain käynnistyksen yhteydessä, joten lataa työkuorma uudelleen tai käynnistä se uudelleen, jotta uusi varmenne otetaan käyttöön.

Sovelluksen julkaiseminen Ingressillä

Jos varmenne on verkkosovellukselle, jonka haluat julkaista internetiin, Ingress voi käyttää Secret-objektia suoraan. Rahti luo vastaavan Route-objektin automaattisesti ja palvelee sitä kyseisellä varmenteella myös uusimisen jälkeen:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
spec:
  rules:
  - host: <HOSTNAME>
    http:
      paths:
      - backend:
          service:
            name: <SERVICE>
            port:
              number: <PORT>
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - <HOSTNAME>
    secretName: hostname-tls

Ingress vai Route

Ingress ja Route ratkaisevat saman käyttötapauksen eri tavoin, eikä Route voi viitata Secret-objektiin: sen varmenne täytyy kirjoittaa suoraan kenttiin spec.tls.certificate ja spec.tls.key. Ingressin käyttäminen on siksi yksinkertaisempi vaihtoehto cert-managerin kanssa, koska uusittu varmenne otetaan käyttöön ilman manuaalista kopiointia. Katso osio Routes, miltä luotu Route näyttää.

Itseallekirjoitetut varmenteet

Itseallekirjoitettuja varmenteita ei ole allekirjoittanut julkinen varmentaja, joten selaimet näyttävät niistä varoituksen. Ne ovat hyödyllisiä salattaessa liikennettä omien sovellustesi välillä Rahdin sisällä, esimerkiksi sovelluksen ja sen tietokannan välillä, tai testaukseen ennen kuin oikea verkkotunnus on saatavilla.

Yksittäistä itseallekirjoitettua varmennetta varten luo Issuer, jossa on tyhjä selfSigned-osio:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned
spec:
  selfSigned: {}

Pyydä sitten siltä varmenne täsmälleen samalla tavalla kuin ACME-myyntäjältä käyttäen Servicen sisäistä DNS-nimeä:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-app-internal
spec:
  secretName: my-app-internal-tls
  issuerRef:
    name: selfsigned
    kind: Issuer
  dnsNames:
    - my-service.my-rahti-project.svc.cluster.local

Oman varmentajan käyttäminen

Jos useat sovellukset tarvitsevat varmenteita, jotka ne voivat myös validoida, allekirjoita ne yhdellä omalla varmentajallasi sen sijaan, että tekisit jokaisesta varmenteesta erikseen itseallekirjoitetun. Varmentajan käyttöönotto vaatii kaksi objektia: itseallekirjoitetun CA-varmenteen, jonka myöntää edellisen osion selfsigned-Issuer, sekä toisen Issuer-objektin, joka allekirjoittaa tällä CA-varmenteella.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-ca
spec:
  isCA: true
  commonName: my-ca
  secretName: my-ca-key-pair
  duration: 43800h # 5y
  issuerRef:
    name: selfsigned
    kind: Issuer
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: my-ca-issuer
spec:
  ca:
    secretName: my-ca-key-pair

Varmenteet, jotka nimeävät my-ca-issuer-arvon issuerRef-kentässään, allekirjoitetaan nyt varmentajallasi. Sovellukset luottavat niihin liittämällä varmenteen Secret-objektin ca.crt-merkinnän ja käyttämällä sitä luotettuna CA-kimppuna.

Warning

my-ca-key-pair-Secret sisältää varmentajasi yksityisavaimen. Kuka tahansa, joka voi lukea sen, voi myöntää varmenteita, joihin sovelluksesi luottavat, joten säilytä sitä projektissa, johon on rajoitettu pääsy, äläkä koskaan kopioi sitä imageen tai Git-repositorioon. Sama huolellisuus koskee minkä tahansa varmenteen Secret-objektin tls.key-merkintää sekä yksityisavainta, joka on kirjoitettu Route-objektin kenttään spec.tls.key.

Cert-managerin toiminnan testaaminen

Nopein tapa tarkistaa, että cert-manager on saatavilla ja toimii projektissasi, on myöntää itseallekirjoitettu varmenne. Se ei tarvitse verkkotunnusta eikä ulkoista palvelua, joten se joko toimii muutamassa sekunnissa tai kertoo, mitä puuttuu. Tallenna tämä tiedostoon cert-manager-test.yaml:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-test
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: cert-manager-test
spec:
  secretName: cert-manager-test-tls
  duration: 24h
  issuerRef:
    name: selfsigned-test
    kind: Issuer
  dnsNames:
    - cert-manager-test.example.com

oc apply -f cert-manager-test.yaml

Tarkista sitten, että varmenne tuli valmiiksi:

oc get certificate cert-manager-test

NAME                READY   SECRET                  AGE
cert-manager-test   True    cert-manager-test-tls   5s

READY: True tarkoittaa, että cert-manager on käynnissä, sillä on oikeudet toimia projektissasi ja se on kirjoittanut Secret-objektin. Voit tarkastella myös itse myönnettyä varmennetta:

oc get secret cert-manager-test-tls -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -subject -issuer -dates

subject=CN=cert-manager-test.example.com
issuer=CN=cert-manager-test.example.com
notBefore=Aug  4 09:00:00 2026 GMT
notAfter=Aug  5 09:00:00 2026 GMT

Aihe ja myöntäjä ovat samat, mikä tekee siitä itseallekirjoitetun. Poista lopuksi testiobjektit:

oc delete -f cert-manager-test.yaml
oc delete secret cert-manager-test-tls

Samat komennot toimivat myös oikeille varmenteille. Jos Certificate-objektin READY-tila pysyy arvossa False, nämä näyttävät, kuinka pitkälle prosessi eteni ja miksi se pysähtyi:

oc describe certificate my-app
oc get certificaterequest,order,challenge
oc describe challenge <challenge_name>

ACME-myyntäjän kanssa varmenne, joka ei koskaan tule valmiiksi, johtuu useimmiten siitä, että verkkotunnus ei vielä osoita Rahtiin, palomuuri estää varmennuspyynnön tai varmentajalla on voimassa nopeusrajoitus.

Lisätietoja

Mukautetut verkkotunnukset ja suojattu tiedonsiirto: vaiheittainen opas, joka kattaa myös DNS-asetukset ja ACME-ohjaimen vaihtoehtona cert-managerille.
Mukautetut verkkotunnukset: mitä Rahti vaatii DNS-tietueilta ja varmenteilta.
cert-managerin dokumentaatio: täydellinen viite myöntäjistä, varmenteista ja vianmäärityksestä.