IBM registry via PaloAlto authentication fails

[moorthi.pongiannan]

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

[kiwi]

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,