Error java.lang.IllegalArgumentException for the field 'appArmorProfile' in the JSON string not defined in the 'V1SecurityContext' properities

[amolpratap-singh]

Description

In client-java version 20.0.1, an error was encountered related to the "appArmorProfile" field not being defined, as detailed below. The Java application, which uses client-java version 20.0.1, was deployed in a Kubernetes pod running on Kubernetes version 1.30.0.

java.lang.IllegalArgumentException: The field appArmorProfile in the JSON string is not defined in the V1SecurityContext properties. JSON: {"capabilities":{"drop":["all"]},"runAsNonRoot":true,"readOnlyRootFilesystem":true,"allowPrivilegeEscalation":false,"seccompProfile":{"type":"RuntimeDefault"},"appArmorProfile":{"type":"RuntimeDefault"}}

at io.kubernetes.client.openapi.models.V1SecurityContext.validateJsonObject(V1SecurityContext.java:434)
        at io.kubernetes.client.openapi.models.V1Container.validateJsonObject(V1Container.java:975)
        at io.kubernetes.client.openapi.models.V1PodSpec.validateJsonObject(V1PodSpec.java:1360)
        at io.kubernetes.client.openapi.models.V1Pod.validateJsonObject(V1Pod.java:280)
        at io.kubernetes.client.openapi.models.V1PodList.validateJsonObject(V1PodList.java:268)
        at io.kubernetes.client.openapi.models.V1PodList$CustomTypeAdapterFactory$1.read(V1PodList.java:300)
        at io.kubernetes.client.openapi.models.V1PodList$CustomTypeAdapterFactory$1.read(V1PodList.java:290)
        at com.google.gson.TypeAdapter$1.read(TypeAdapter.java:204)
        at com.google.gson.Gson.fromJson(Gson.java:1227)
        at com.google.gson.Gson.fromJson(Gson.java:1137)
        at com.google.gson.Gson.fromJson(Gson.java:1047)
        at com.google.gson.Gson.fromJson(Gson.java:1014)
        at io.kubernetes.client.openapi.JSON.deserialize(JSON.java:722)
        at io.kubernetes.client.openapi.ApiClient.deserialize(ApiClient.java:895)
        at io.kubernetes.client.openapi.ApiClient.handleResponse(ApiClient.java:1105)
        at io.kubernetes.client.openapi.ApiClient.execute(ApiClient.java:1029)
        at io.kubernetes.client.openapi.apis.CoreV1Api.listNamespacedPodWithHttpInfo(CoreV1Api.java:26426)
        at io.kubernetes.client.openapi.apis.CoreV1Api.access$43300(CoreV1Api.java:77)
        at io.kubernetes.client.openapi.apis.CoreV1Api$APIlistNamespacedPodRequest.execute(CoreV1Api.java:26593)

However, when the same client-java 20.0.1 version was used with the older Kubernetes version 1.28.2, no exception related to the "appArmorProfile" field was triggered. The client-java 20.0.1 version works without issues on Kubernetes version 1.28.2.

Client Version
20.0.1

Kubernetes Version
1.30

Java Version
Java 17.0.11

To Reproduce
Steps to reproduce the behavior:

Write a Java client with 20.0.1 as demonstrated in the sample code below. This code will throw an exception on Kubernetes version 1.30 but not on Kubernetes version 1.28.

code

CoreV1API coreAPI = new CoreV1API()

try {
    APIlistNamespacedPodRequest listNamespacePod = coreApi.listNamespacedPod(System.getenv(ENV_NAMESPACE));

    listNamespacePod.labelSelector("vault-config-job").limit(3).timeoutSeconds(10);
                
    V1PodList podList = listNamespacePod.execute();
} catch (ApiException ex) {
    System.out.println("api error code:" + ex.getCode() + " resonse body: " + ex.getResponseBody() + " exception: " + ex});
} catch (Exception ex) {
    System.out.println(ex);
    ex.printStackTrace();
}

Expected behavior
No exception or error should be thrown since the client-java version 20.0.1 works on Kubernetes version 1.28. However, it breaks on Kubernetes version 1.30. The expectation was that it should function without issues on both versions.

Server:

• OS: [SUSE Linux Enterprise Server 15 SP5]

Additional context

I then modified the client-java version 20.0.1 and built it to get the jar file. The modification, as described below, resolved the issue and the exception no longer occurred, allowing it to work seamlessly.

The fix was implemented in the V1SecurityContext.class file at line number 317, which resulted in the successful operation.

openapiFields.add("appArmorProfile");

[brendandburns]

20.0.1 was generated for 1.28.x Kubernetes APIs, it's only guaranteed to work against Kubernetes 1.26, 27 and 28. We've regenerated for 1.30 at HEAD and we need to cut a release. Can you test against HEAD and see if it works?

[amolpratap-singh]

I tested with the HEAD tag on Kubernetes versions 1.30 and 1.28, and found no issues or exceptions related to appArmorProfile field.

Thank you for the information. Could you please let me know when the new version of client-java will be available? We've identified a vulnerability in version 19.0.0, which is resolved in version 20.0.1. However, 20.0.1 has another issue as described in the ticket.

[amolpratap-singh]

@brendandburns can u provide me answer for above query it will be helpful

[brendandburns]

@amolpratap-singh please try the 20.0.1-legacy client version. That is built using the same code generator as 19.0.0 and it should avoid this bug also.

You'll want to eventually switch back off the legacy version to the newer code generator.

[tsaarni]

@amolpratap-singh please try the 20.0.1-legacy client version. That is built using the same code generator as 19.0.0 and it should avoid this bug also.
You'll want to eventually switch back off the legacy version to the newer code generator.

Hi @brendandburns 👋 Legacy client was indeed able to gracefully ignore the new (unknown) field. From your comment I understood that client-java with new code generator will be also to handle them in the future - Is there an issue to follow that?