RA489
commented
4 years ago /triage support
Closed AndrewPanov closed 3 years ago
RA489
commented
4 years ago /triage support
fejta-bot
commented
3 years ago Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
AndrewPanov
commented
3 years ago /remove-lifecycle stale
priyawadhwa
commented
3 years ago Hey @AndrewPanov apologies for the delayed response here. Are you still seeing this issue with the most recent version of minikube v1.17.0?
AndrewPanov
commented
3 years ago @priyawadhwa I may try to reproduce it with the most recent version and give you feedback, as for now i don't know
AndrewPanov
commented
3 years ago @priyawadhwa I have succeeded to reproduce the same bug and behavior on minikube 1.17.1
Karmavil
commented
3 years ago @AndrewPanov
I'm trying to improve the description of an issue I opened yesterday (I'm reading documentation right now). I'm not sure if it is related with your problem, but maybe it is.
You're getting this particular message: no basic auth credentials
So in my limited experience I see 2 options here.. your credentials are wrong or your repository address.
Let me know if it is related to link or mention this issue. Thanks
priyawadhwa
commented
3 years ago Hey @AndrewPanov have you tried using our registry-creds addon? Documentation for it can be found here and might help fix your auth failure: https://minikube.sigs.k8s.io/docs/handbook/registry/#using-a-private-registry
Karmavil
commented
3 years ago @AndrewPanov Sorry, I'm NOT trying to say that you made a mistake with your credentials, I'm trying to say that maybe the auth is the problem. Let me explain:
@priyawadhwa is there a standard for repository endpoints? (so to speak) Because as you can see in k8s doc: username, pasword, email, auth.. all is there and it's not clear which params should I use As you can see in my last reply I've been having some troubles with the k8s documentation pulling from a private docker hub repo.
I followed your suggestion and this is my conclusion: minikube is saving my .dockerconfigjson with a structure similar to what Andrew described in this issue.. (apparently he's able to login with that structure to whatever nexus3 is)
this is the dpr-secret that minikube made for me: {"auths":{"https://index.docker.io/v1/":{"auth":"bXluYW1lOm15cGFzc3dvcmQK","email":"none"}}}
let me expand it:
{
"auths": {
"https://index.docker.io/v1/": {
"auth":"myname:mypassword",
"email":"none"
}
}
}That doesn't work for docker hub. And yes I told my deployments to use the imagePullSecrets (BTW the minikube documentation should mention if that's necessary, and how to delete or override a previous configuration 'cos I tried re-configure or reset choosing n for all options and the previous configuration is still here... I had to disable the addon).
However if I simply set a Secret, set imagePullSecrets, and use the following structure it works perfectly fine:
{
"auths": {
"https://index.docker.io/v1/": {
"username":"myname",
"password":"mypassword"
}
}
}data:
.dockerconfigjson: e2F1dGhzOiB7aHR0cHM6Ly9pbmRleC5kb2NrZXIuaW8vdjEvOiB1c2VybmFtZTpteW5hbWV9fSBwYXNzd29yZDpteXBhc3N3b3JkfX0KYou get banned after too many failed attempts so that's pretty much all that I can get for you.. except for this last example:
{
"auths": {
"https://index.docker.io/v1/": {
"username":"myname",
"password":"mypassword"
},
"email": "none"
}
}this is the error: json: cannot unmarshal string into Go struct field DockerConfigJSON.auths of type credentialprovider.dockerConfigEntryWithAuth
I was curious and that's why I asked about standard procedures to login using token vs username/password vs email/password..
If they have a type credentialprovider.dockerConfigEntryWithAuth why I cannot login using auth? anyway I hope this information not strictly related with this issue help someone to deal with this problems
Karmavil
commented
3 years ago EDIT: here I am again with a new edit.. As I said before in this reply, the format below works. (userID:token or userID:password)
(I fixed this answer previously because I thought it worked by mistake, but instead I made the mistake right there actually .. I forgot to include the imagePullSecret
# config.json
{
"auths": {
"https://index.docker.io/v1/": {
"auth":"bXluYW1lOm15cGFzc3dvcmQK"
}
}
}# secret
apiVersion: v1
data:
.dockerconfigjson: ewogICAgImF1dGhzIjogewogICAgICAgICJodHRwczovL2luZGV4LmRvY2tlci5pby92MS8iOiB7CiAgICAgICAgICAgICJhdXRoIjoiYlhsdVlXMWxPbTE1Y0dGemMzZHZjbVFLIgogICAgICAgIH0KICAgIH0KfQ==
kind: Secret
metadata:
name: my-credential
namespace: default
type: kubernetes.io/dockerconfigjson
# your por, deployment, or statefulset
...
containers:
- image: dos:latest
name: dbg
...
imagePullSecrets:
- name: my-credential@priyawadhwa ok, i'll try to use that and see that happens @Karmavil tl;dr sorry 1) everything is ok with creds or address 2) all creds are stored like in 13 step (auths->url->auth->base64encoded) 3) mbe imagepullsecrets may help for somehow, i didn't check it
Karmavil
commented
3 years ago I know sorry about that. It was my fault from the moment I posted code that no one asked for, on an issue I didn't open. But I have issues downloading from a private repository like docker with minikube as priyadhwa suggested and I don't want to duplicate and Issue that I can easily workaround. I don't need that functionality to be honest, but it's really useful to keep your credentials out of repositories. I will keep an eye on this issue (as a user of course). Feedback is welcome
Steps to reproduce the issue:
deploy nexus3 (sonatype/nexus3:3.25.0 image) container
Setup nexus3 docker registry repository
Apply http connector (i have 8083 port)
Push jar there (i have ci-cd project and so on)
start minikube with command
minikube startadd insecure registry ~/.docker/config.json 'nexus3:8083'; like that
minikube start --insecure-registrydidnt work for me :(apply minikube configs with
minikube startconnect minikube to docker network with nexus container; in my case
docker network connect docker_default minikuberun
docker exec -it minikube bashlogin in registry with
docker login nexus3 -u {user} -p {pass}ALL SETUP IS FINISHED
Apply deployment with
kubectl apply -f {path}/deployment.yamlbtw deployment.yaml:run
minikube logs -fRead unsuccessful message:
in minikube container run
cat ~/.docker/config.jsonAnd creds are the same as i put on
docker logincommandRemove all deployments with
kubectl delete deployments --allin minikube container run
docker pull nexus3:8083/com.panov/ci-cd:0.0.1-SNAPSHOTSee successful pulling start
Fine. Pull whole image
Rerun deployment outside with
kubectl apply -f {path}/deployment.yamlSee successful logs or run
kubectl get deploymentsFull output of
minikube startcommand used, if not already included: š minikube v1.12.2 on Darwin 10.15.5 āØ Using the docker driver based on user configuration š Starting control plane node minikube in cluster minikube š„ Creating docker container (CPUs=2, Memory=4000MB) ... ā This container is having trouble accessing https://k8s.gcr.io š” To pull new external images, you may need to configure a proxy: https://minikube.sigs.k8s.io/docs/reference/networking/proxy/ š³ Preparing Kubernetes v1.18.3 on Docker 19.03.8 ... š Verifying Kubernetes components... š Enabled addons: default-storageclass, storage-provisioner š Done! kubectl is now configured to use "minikube"ā /usr/local/bin/kubectl is version 1.16.6-beta.0, which may be incompatible with Kubernetes 1.18.3. š” You can also use 'minikube kubectl -- get pods' to invoke a matching version
Optional: Full output of
minikube logscommand: Logs are in details