ConfigBuilder.withClientKeyData()
is broken in 3.1.8.
withClientCertData
and withCaCertData
work just fine.
The following code snippit shows the problem and the workaround.
boolean useWorkaround = true;
if (useWorkaround) {
File tempWorkaroundFile = null;
try {
tempWorkaroundFile = java.nio.file.Files.createTempFile("workaround", "tmp").toFile();
Files.write(key, tempWorkaroundFile, Charsets.UTF_8);
configBuilder = configBuilder.withClientCertFile(tempWorkaroundFile.getAbsolutePath());
} finally {
tempWorkaroundFile.delete();
}
} else {
configBuilder = configBuilder.withClientKeyData(key);
}
The problem manifests as:
Caused by: java.io.IOException: PEM is invalid: no begin marker
at io.fabric8.kubernetes.client.internal.CertUtils.decodePem(CertUtils.java:220)
at io.fabric8.kubernetes.client.internal.CertUtils.createKeyStore(CertUtils.java:105)
at io.fabric8.kubernetes.client.internal.CertUtils.createKeyStore(CertUtils.java:196)
at io.fabric8.kubernetes.client.internal.SSLUtils.keyManagers(SSLUtils.java:127)
at io.fabric8.kubernetes.client.internal.SSLUtils.keyManagers(SSLUtils.java:121)
at io.fabric8.kubernetes.client.utils.HttpClientUtils.createHttpClient(HttpClientUtils.java:64)
... 38 more
ConfigBuilder
appears to be auto-generated so it is not clear to me how to fix this.
解决方案
It’s not a bug I learned with trial and error. Although it would make sense that the method would accept the contents of the file (which is already armored plaintext), it wants to see the key/cert data base64 encoded again.
Ps:看源码就知道,每次密钥文件会进行 base64 解密,但是这个解密并不是必然事件,随机性的,所以当不必要 base64 解密的时候但是源码进行了解密的话就会出现乱码问题,导致上面的报错信息,所以可以统一给密钥文件先加密 base64。