Kuadrant / Kuadrant/dns-operator

(proposal) Support more standard credential chains

Open
#458 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
12
Forks
23
Avg merge
1d 4h
Merged PRs (30d)
14

Description

**Description**
Users running Kubernetes with EC2 instances will often prefer to use IRSA to pull dynamic IAM credentials for a given role, rather than managing static credentials.

**Implementation proposals:**
1. Allow user to provide an IRSA enabled ServiceAccount in place of the secret
2. Support environment variables entirely as a valid credentials pattern on the operator

**Relevant code section:**
https://github.com/Kuadrant/dns-operator/blob/c4c1d820296a5e113ff99f28dbe6cce2e2db3c0b/internal/provider/aws/aws.go#76

(Lines 76-88)

I'm open to contributing this change myself, when I have time this weekend

---

Update (05/27): I've started on this over the long weekend and believe I have working implementations for the `google` and `aws` provider so far, I'm not very familiar with AKS so its a bit more confusing how they expect those credentials to be handled but I'm working through it.

I believe the best pattern to enable this would be to add a new `provider` field to the `DNSRecord` custom resource, as shown below. For `aws` and `google`, the name of the cloud provider is enough to handle the default credential chain; for azure this is looking more complicated, so some optional params may need to be passed (e.g. `resourceGroup` for `azure`).

```yaml
apiVersion: kuadrant.io/v1alpha1
kind: DNSRecord
metadata:
name: simple-dns
namespace: dnstest
spec:
endpoints:
- dnsName: ${KUADRANT_SUB_DOMAIN}
recordTTL: 60
recordType: A
targets:
- 172.32.200.17
# new field, mutually exclusive with `providerRef`
provider:
name: aws # one of: aws, azure, google
# resourceGroup: test # for azure provider
rootHost: ${KUADRANT_SUB_DOMAIN}
```

I believe long term, it would be best to deprecate the static credentials in secrets; if needed, those credentials could be mounted to the operator pod & these credential chains would work with minimal changes.

Contributor guide

Open the contributing guide

Research direction

Start with internal/provider/aws/aws.go at lines 76-88, then inspect the DNSRecord and provider implementations for AWS, Google, and Azure. Define the supported credential-chain and provider-selection behavior, including IRSA, environment variables, and the relationship to providerRef; done means the agreed design is implemented and covered for each supported provider.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, azure, go, google-cloud, kubernetes
Domain
authentication, cloud, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.