• Geoff Simmons's avatar
    Refactor the mechansim for making TLS Secrets available to haproxy. · b5d6cef1
    Geoff Simmons authored
    The haproxy container now runs the app k8s-crt-dnldr, and no longer
    runs http-faccess. See https://code.uplex.de/k8s/k8s-crt-dnldr
    
    k8s-crt-dnldr runs a k8s client that reads Secrets, filtered for
    RLS (type:kubernetes.io/tls). It provides a REST API with which a
    client can instruct it to write (PUT) or remove (DELETE) a pem
    file (concatenated crt and key) corresponding to a TLS Secret in
    the cluster. By default, these are written to /etc/ssl/private,
    where haproxy reads certificates. After the next haproxy reload
    following the write or delete, haproxy will use or not use the
    certificate.
    
    Once k8s-crt-dnldr has been instructed to store a Secret, it
    responds to Update and Delete events for the Secret by updating
    or deleting the file on its own. The controller currently sends
    commands to do so as well, but in practice the k8s-crt-dnldr has
    already changed the certificate itself (this is not an error).
    
    This means that viking Pods must have RBAC rights to read
    Secrets (the fact that these are filtered for TLS is not
    expressible in RBAC). That in turn means that viking Pods
    must be assigned a service account name, to get the RBAC
    role binding.
    
    The controller no longer needs RBAC write privileges for Secrets,
    and the "tls-cert" Secret with the hard-wired name is no longer
    necessary. The Secret volume that projects "tls-cert" into viking
    Pods has been removed.
    
    The port faccess in the headless Service for viking admin
    has been renamed to crt-dnldr.
    
    Addresses #36
    b5d6cef1
service.go 11.5 KB