Documentation ¶
Index ¶
- func Serve(ctx context.Context, slvr *Solver) error
- type Solver
- func (s *Solver) CleanUp(ch *whapi.ChallengeRequest) error
- func (s *Solver) Group() string
- func (s *Solver) Initialize(c *rest.Config, stopCh <-chan struct{}) error
- func (s *Solver) Name() string
- func (s *Solver) Present(ch *whapi.ChallengeRequest) error
- func (s *Solver) Run(ctx context.Context) error
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func Serve ¶
Serve requests on port 4443 for the DNS-01 Solver through Kubernete's APIService(1) and using self-signed certificates created by Phonebook's helm chart. The Service runs through HTTPS but is only used internally by Kubernetes as described by cert-manager's documentation on DNS-01 webhooks integration (2).
Most of the code here was copied from Cert-manager's abstraction layer. By default, cert-manager expects the webhook to run isolated as its own binary, which means their webhook abstraction deals with arguments parsing and server configuration.
While this may work for other integrations, it caused a bunch of weird issues for Phonebook as the server runs inside the main controller. First, the command line arguments conflicts with the ones provided for the controller then, the client Phonebook's solver wants to use is different than the one passed by cert-manager's abstraction.
For this reason, a lot of the code was copied over so the Aggregation layer can be properly configured with the APIService and Phonebook can still interact with DNSRecord the same way the rest of the operator is.
1. https://kubernetes.io/docs/tasks/extend-kubernetes/configure-aggregation-layer/ 2. https://cert-manager.io/docs/configuration/acme/dns01/webhook/
Types ¶
type Solver ¶
func NewSolver ¶
Create a new solver to be used with Phonebook.
The Name of the solver is the name of the interface as defined by RFC2136. This is not a user-defined value but rather the name defined in the helm chart that is Phonebook specific.
The manager is used to get information about the API Group and to retrieve its fully configured client.
The Solver returned is fully configured and ready to go. It won't start accepting challenges until `Run()` is called on the solver.
func (*Solver) CleanUp ¶
func (s *Solver) CleanUp(ch *whapi.ChallengeRequest) error
Request to clean up the request after a success/failure. At this point, the DNSRecord was possibly created and it needs to be deleted so Phonebook can remove it from the Provider.
As described in the Present method, records for challenges have a generic label associated with them. The CleanUp method needs to retrieve all dsn records that includes this label and do client side filtering to only delete records that have a matching challenge Key.
It's possible that the DNSRecord was already deleted, or that more than 1 record with the same key exists. All in all, any record that has a matching label & challenge key needs to be deleted when this method returns.
Deleting the record will have Phonebook run through the finalizer and delete the record on the provider's side.
func (*Solver) Initialize ¶
Initialize is a no-op to complete the Solver's Interface. The client is not needed as one was already provided by the manager during the creation of the solver.
func (*Solver) Name ¶
Name is the name specified by Phonebook and is required to match the APIServer resource created by the helm chart.
func (*Solver) Present ¶
func (s *Solver) Present(ch *whapi.ChallengeRequest) error
Present a challenge to the solver. The Challenge Request comes from cert-manager through the webhook integration. Once presented with a challenge, a DNS Record needs to be created with the challenge information so cert-manager can assert that the domain is owned by user of Phonebook.
The DNSRecord created for a challenge will have a generic "challenge" label added to it. This will allow cleanup operations to get a list of all challenges and remove those that needs to be cleaned up. Now, in an ideal world, the label would have been specific enough so cleanup duties would be able to retrieve only the proper challenge records. For example, the label could hold the ResolvedFQDN and the cleanup could retrieve DNS Records by ResolvedFQDN. It is, however, impossible to implement safely as Labels have a stricter validation set(1) compared to FQDN(2).
The tradeoff is to label challenges and do client-side filtering inside the CleanUp method instead. It is reasonable to think that the number of challenges at any given time is pretty low, the bandwidth/CPU to filter those records on the client side seems acceptable at this time.
1. https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set 2. https://www.ietf.org/rfc/rfc1034.txt