-
Feature Request
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
None
-
Product / Portfolio Work
-
None
-
False
-
-
None
-
None
-
None
-
-
None
-
None
-
None
-
None
-
None
Base64 Credential Pitfall in Azure/OpenShift Installations:
When working with OpenShift Container Platform (OCP) installations on Azure or Azure Stack Hub, it's common to handle credentials using base64-encoded strings. However, a subtle issue can arise during manual base64 encoding, especially when:
~~~
data:
azure_client_id: dfdgergrtgrtghrthrthrthrthtryhythCg==
azure_client_secret: fgbfgbfgbfgbfgbgfnfghcvbc
azure_region: fgbfgbfgbfgbfgbCg==
azure_resource_prefix: YWFobG5vbnByb2QK
azure_resourcegroup: QWlycG9ydC1EZXYtRVNCLVJHCg==
azure_subscription_id: fgbfgbfgbgfhnvbnbfgnhtmnhfdvvCg==
azure_tenant_id: ggddvbfgbfgjhgjnbfvvcxvdfbvfdbfgbcvcbCg==
~~~
The base64 string encoding accidentally includes a newline character, represented by the Cg== suffix, often unnoticed.
Why This Is Hard to Spot:
When decoding such strings, the newline character is not visible, and the value may appear valid:
~~~
echo "MTA1OG..." | base64 --decode
…still gives what looks like a valid ID.
~~~
However, the actual decoded string is one byte longer (e.g., 37 bytes instead of the expected 36 for a tenant ID), which silently breaks the installer.
During cluster creation, this results in vague or misleading errors such as:
~~~
Error building cloud provider client, err: invalid tenantID. You can locate your tenantID by following the instructions listed here: https://docs.microsoft.com/partner-center/find-ids-and-domain-names
Or, if the newline character is caught earlier (e.g., using the openshift-install binary):
~~~
- ./openshift-install create cluster
...
FATAL failed to fetch Metadata: ... invalid character '\n' in string literal
~~~
Where we get lost to investigate further, but the thing is credentials string for example
tenantID is always 36 bytes, but in case if the newline character is present it becomes
37 bytes. With which we can spot the issue here.
But customer often ignore new line, here.
Proposed Solutions can be:
These errors can be confusing, especially since the credentials may look correct when manually verified.
Validate decoded values for expected length (e.g., tenant ID = 36 chars).
Use tools that automatically handle encoding properly, like the openshift-install CLI or oc when possible.
Ideally, the installer should validate and reject credentials with trailing newlines early, with a clear error message.
Alternatively, the installer could strip the newline character automatically if found.
Note: This is specifically issue with the manually handled base64 conversion, as I tried reproducing this in IPI Installation method we provide the credentials, I tried providing new line in azure_tenant_id where it error's out in very early stage of installation before starting it,
below is the error:
~~~
- ./openshift-install create cluster
? SSH Public Key /root/.ssh/id_rsa.pub
? Platform azure
FATAL failed to fetch Metadata: failed to fetch dependency of "Metadata": failed to fetch dependency of "Cluster ID": failed to fetch dependency of "Install Config": failed to fetch dependency of "Base Domain": failed to generate asset "Platform": invalid character '\n' in string literal
~~~