CI Build-image-and-push step doesn't support plain HTTP anonymous image repo?

[I’d show more pictures but new users are apparently limited to the number of media stuffs they can attach…]

Steps to produce issue:

  1. Create a Docker Registry connector that targets a plain HTTP image repo that doesn’t use any user authentication (anonymous). In my case the registry is in a container built from DockerHub’s registry:2 image. The container runs in Docker Desktop on my local machine. The container is accessible on my local machine at localhost:5000. The connector is added to a Kubernetes delegate that itself runs in Docker Desktop’s Kubernetes implementation on my local machine. “docker-desktop” is the name of the single node in my Kubernetes cluster, which also happens to be the machine on which the Docker image registry is accessible on port 5000.
    Docker registry connector config is as follows. Provider type: Other (but DockerHub yields the same results) URL: http://docker-desktop:5000/v2. No authentication (anonymous).
  2. Create a CI pipeline that includes a Build stage.
  3. Configure the build stage infrastructure such that it uses Kubernetes. In my case, I’m using the same Kubernetes cluster that my delegate is running in but I gave the build infrastructure its own namespace to run in.
  4. Add to the stage’s execution a build step that builds and pushes an image to a Docker registry.
    In my config I specify the Docker repository as docker-desktop:5000/kubedemo-store and reference the Docker connector created in step 1 (which references a plain HTTP Docker registry).
  5. Run the build.

Expected: It builds the image and pushes it to the configured repo.
Actual: The console output for the Docker image build says time=“2022-07-29T12:54:34Z” level=fatal msg=“Username must be specified”.

I did some digging and found out that Harness will try to build the image using the image plugins/kaniko:1.6.0. I played around with this image directly to understand its behaviour and I discovered that it generally outputs this “Username must be specified” message when there’s something wrong with the input arguments to its executor command (for example, don’t pass any arguments). I can’t say for sure what Harness is doing however.

Interestingly, if I add fake credentials to the Docker registry connector in step 1 and follow all the other steps as stated above, Kaniko outputs something different:

Now I can see what Harness is passing to Kaniko’s executor command. Looks right to me except Kaniko complains that it was expecting docker-desktop:5000/v2 to be accessible over HTTPS but it’s not HTTPS. Playing around with Kaniko myself it looks like it can work if I pass the --insecure flag to the executor command.


  1. Is Harness not handling anonymous Docker registries correctly? Am I doing something wrong? It looks to me like I had to add fake credentials to my Docker registry connector to get Harness to invoke Kaniko in a way that Kaniko likes.
  2. Even with the fake credentials work around stated above, I couldn’t find any way to get Kaniko to connect to my plain HTTP Docker registry. My own experimentation shows the --insecure flag should be passed to the Kaniko executor when the registry is plain HTTP but I couldn’t find any way to get Harness to do this. Should Harness automatically pass the --insecure flag when it sees in the connector config that the registry is on plain HTTP?

@leon-olszewski, The support for insecure flag is not present. It will require an enhancement request. Also, anonymous Docker registries without credentials for push is not a real usecase. This scenario has not been tested

Thanks for the response. For context, I’m a developer that’s evaluating Harness. This is my story: I made a free account with Harness, spun up the delegate on my dev machine and had trouble getting Harness to build and push my images. Harness may disagree with this but playing around with software prospects in this way seems like a reasonably “real usecase” to me (I don’t want to setup TLS and authentication on my local dev machine to make Harness happy). I was even thinking that maybe there could be a way for devs to try out a whole build → deploy sequence locally to get confidence in their changes before committing them. That scenario may involve some non-HTTPS resources, I don’t know.

Anyway, thanks again for the response. I won’t open an enhancement request (not even sure how) until my company commits to Harness because I have hope that Harness itself would see value in making its product work in insecure contexts. If nothing else, a note in the documentation explaining what’s not supported would be very helpful. I didn’t see such notes when I looked, maybe I missed it.

Hey @leon-olszewski, thanks for trying out harness, to try out whole build locally I would suggest you to try out the opensource version of Harness-cd-community also yes every use case is important for us we are surely looking into ways to carter everyone’s need.

You could go to the help section present in the bottom left corner and in the resource center you could submit a ticket for any enhancement request