dogmatiq / proclaim

🚧 A Kubernetes controller and CRD that publishes DNS-SD records.

Proclaim

A Kubernetes controller and CRD that publishes DNS-SD records.

Proclaim defines a DNSSDServiceInstance Kubernetes custom resource that describes a DNS-SD service instance to be advertised on one of the supported DNS provider implementations:

• Amazon Route 53
• DNSimple

Deployment

Helm

Proclaim can be deployed using the Helm chart in this repository. The default values are suitable for most deployments.

# configure the "proclaim" secret (see below)
helm pull https://github.com/dogmatiq/proclaim/tree/main/charts dogmatiq/proclaim
helm install proclaim --values values.yaml dogmatiq/proclaim

Please note that pulling the Helm chart from the main branch will always install the latest version. Use a version number (e.g. v0.4.2) to install a specific version.

Configuration

Each provider needs its own credentials which are stored in a Kubernetes secret named proclaim. This secret is NOT created by the Helm chart.

Amazon Route 53

1. Set the proclaim.providers.route53.enabled value to true in the Helm chart values file.
2. Configure AWS credentials:
   • IRSA is recommended when running under EKS. The Helm chart creates a service account which can be annotated with IAM-specific annotations by setting the proclaim.serviceAccount.annotations value in the values file.
   • Otherwise, the standard AWS environment variables (AWS_ACCESS_KEY_ID, etc) can be added to the proclaim secret.

The example IAM policy illustrates the precise set of permissions required for Proclaim to function.

DNSSimple

1. Set the proclaim.providers.dnsimple.enabled value to true in the Helm chart values file.
2. Add a DNSIMPLE_TOKEN key to the proclaim secret. The token can be either a "user" token or an "account" token.

proclaim's Issues

Implement a validating webhook server.

There doesn't appear to be a way to represent a oneOf: [type: boolean, type: string] in the CRD and still remain a "structural" spec according to K8s subset of support for OpenAPI v3.

A validating webhook server would let us keep the current attribute format (current as of v0.3.0) and still prevent the user from defining invalid attribute values.