Kuadrant / Kuadrant/dns-operator
(proposal) Support more standard credential chains
- 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
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