IBM registry via PaloAlto authentication fails

moorthi.pongiannan — Tue, 30 Jun 2026 13:01:14 GMT

Hi,

Here's a polished rewrite:

Just wondering if anyone has come across an IBM Container Registry authentication issue where the registry traffic is routed through PaloAlto Akamai geo-location edge servers (for example, cp.icr.io).

I experienced intermittent authentication failures where the login process would hang and never complete. After some investigation, I found that adding a static entry for cp.icr.io (pointing it to a specific IP address, xxx.xxx.xxx.xxx) resolved the issue and authentication started working consistently.

Has anyone seen similar behavior or identified a root cause related to Akamai edge servers, DNS resolution, or geo-location routing?

host cp.icr.io
cp.icr.io is an alias for geo.icr.io.
geo.icr.io is an alias for geo.global.icr.io.akadns.net.
geo.global.icr.io.akadns.net is an alias for uk.icr.io.akadns.net.
uk.icr.io.akadns.net has address 158.176.193.128

Re: IBM registry via PaloAlto authentication fails

kiwi — Wed, 01 Jul 2026 15:05:50 GMT

Hi @moorthi.pongiannan ,

This is a classic issue when dealing with services hosted behind aggressive Content Delivery Networks (CDNs) like Akamai.

Because IBM's registry (cp.icr.io) uses Akamai for geo-location routing, its public IP addresses change constantly based on load balancing and location.

By mapping a static IP to cp.icr.io, you essentially froze the destination IP in place, ensuring the firewall and the client are always aligned.

The risk with the static fix is that if Akamai deprecates, rotates, or changes that specific IP on IBM's backend, your container registry connection will break completely.

Instead, consider tweaking FQDN refresh times to it queries the DNS more aggressively to keep up with Akamai's changes.

Best,

topic Re: IBM registry via PaloAlto authentication fails in General Topics

IBM registry via PaloAlto authentication fails

Re: IBM registry via PaloAlto authentication fails