aws / aws/eks-anywhere

registryMirrorConfiguration does not work with self-signed private docker registries.

Open
#5,232 3 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
2.1k
Forks
328
Avg merge
1d 4h
Merged PRs (30d)
9

Description

**What happened**:
I am trying to provision an EKS-A cluster with bottlerocket nodes. I have a private docker registry configured with self-signed certificates. I have set the `registryMirrorConfiguration` section of the Cluster resource as documented.

```
registryMirrorConfiguration:
endPoint:
authenticate: true
caCertContent: |
-----BEGIN CERTIFICATE-----
MIIE....
```

When provisioning the cluster I get the following error

```bash
sudo eksctl anywhere create cluster --hardware-csv hardware.csv -f cluster.yaml'
Warning: The recommended number of control plane nodes is 3 or 5
Warning: The recommended number of control plane nodes is 3 or 5
Logging in to docker registry :443
Error: Error response from daemon: Get "https://:443/v2/": x509: certificate signed by unknown authority
```

**What you expected to happen**:
The eks-a cluster should be provisioned with insecure registries.

**How to reproduce it (as minimally and precisely as possible)**:
* Provision a private registry with self-signed certificates.
* In the EKSA cluster configuration add the `registryMirrorConfiguration` section with the required details.
* The certificate used in the EKSA cluster configuration is the same as used in a docker client.

**Anything else we need to know?**:
I am using the bottlerocket host OS for deploying the cluster.

**Environment**:
- EKS Anywhere Release: v0.14.2
- EKS Distro Release: 1.24

Contributor guide

Open the contributing guide

Research direction

Start at the `registryMirrorConfiguration` handling used by `eksctl anywhere create cluster`, with attention to the Bottlerocket path and Docker registry login. Reproduce the self-signed registry setup from the issue using EKS Anywhere v0.14.2 and verify how `caCertContent` is passed. Done means the configured certificate is trusted and cluster provisioning succeeds without the x509 error.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, docker, go, kubernetes
Domain
cli, cloud, devops, infrastructure
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.