containerd insecure registry support along with auth

[kranthikirang]

What would you like to be added: containerd to support insecure registries + auth; it is possible to use the auth for secure registries as well in few prod envs.

Why is this needed: Currently we support docker with insecure + secure registries; We need to add the same support to both containerd and cri-o

[kranthikirang]

I think we can close this since latest kubespray version has extra args option; We can pass all extra args needed for cri plugin. I was actually trying to propose the following change

{% if 'registries' in containerd_config %}
[plugins.cri.registry]
[plugins.cri.registry.mirrors]
{% for registry, addr in containerd_config.registries.items() %}
[plugins.cri.registry.mirrors."{{ registry }}"]
endpoint = ["{{ ([ addr ] | flatten ) | join('","') }}"]
{% endfor %}
[plugins.cri.registry.configs]
{% for registry, addr in containerd_config.registries.items() %}
{% if 'https://' in "{{ addr }}" %}
[plugins.cri.registry.configs."{{ registry }}".tls]
{% else %}
[plugins.cri.registry.configs."{{ registry }}"]
insecure_skip_verify = true
{% endif %}
{% endfor %}
{% endif %}

{% if 'registry_credentials' in containerd_config %}
{% for rc in containerd_config.registry_credentials %}
[plugins.cri.registry.configs."{{ rc.registry }}".auth]
{% if rc.username %}
username = "{{ rc.username }}"
{% endif %}
{% if rc.password %}
password = "{{ rc.password }}"
{% endif %}
{% endfor %}
{% endif %}

[kranthikirang]

Extra config to be put in {{ containerd_cfg_dir }}/config.toml literally

containerd_extra_args: ''

[kranthikirang]

perhaps we can use containerd_extra_args to pass insecure registry, + registry auth

[faust64]

Insecure registries already can be configured from the containerd_config variable, using something like this:

containerd_config:
[...]
  registries:
    "registry.default.svc.cluster.local:5000": "http://registry.default.svc.cluster.local:5000"

As for authentication, the following was just merged: #7868

[floryut]

Closing then ? (thanks @faust64)

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale