How use spring-cloud-starter-kubernetes-client-config if rbac resources manipulation deprecated in our clusters

[pshakhov]

Describe the bug Now i using implementation("org.springframework.cloud:spring-cloud-starter-kubernetes-client-config:2.1.1") for working with configmaps. Spring boot 2.6.4. org.springframework.cloud:spring-cloud-dependencies:2021.0.1

Our cluster policies declines creating rbac manifests (clusterrolebindings etc.).

If i remove clusterrolebindings manifests, application cant get configmap. But when i mount configmaps to deployment manifest and uses in bootstrap.yml paths to mounted configs (like 1st answer from https://stackoverflow.com/questions/56863782/cannot-read-configmap-with-name-xx-in-namespace-default-ignoring ), application successfully gets configmap and works with it.

But, in deployed without rbac manifests apps pod logs:

2022-04-18 18:57:30.425 DEBUG 1 --- [           main] o.s.c.k.c.c.KubernetesClientConfigUtils  : Config Map namespace from normalized source or passed directly : our-ci
2022-04-18 18:57:30.425 DEBUG 1 --- [           main] o.s.c.k.c.c.KubernetesClientConfigUtils  : Config Map namespace from normalized source or passed directly : our-ci
2022-04-18 18:57:30.425 DEBUG 1 --- [           main] .KubernetesClientConfigMapPropertySource : Loading ConfigMap with name 'our-ci-example-multi-module-one-common' in namespace 'top-ci'
2022-04-18 18:57:30.733  WARN 1 --- [           main] .KubernetesClientConfigMapPropertySource : Unable to get ConfigMap top-ci-example-multi-module-one-common in namespace our-ci

io.kubernetes.client.openapi.ApiException: 
	at io.kubernetes.client.openapi.ApiClient.handleResponse(ApiClient.java:974)
	at io.kubernetes.client.openapi.ApiClient.execute(ApiClient.java:886)
	at io.kubernetes.client.openapi.apis.CoreV1Api.listNamespacedConfigMapWithHttpInfo(CoreV1Api.java:28375)
	at io.kubernetes.client.openapi.apis.CoreV1Api.listNamespacedConfigMap(CoreV1Api.java:28263)
	at org.springframework.cloud.kubernetes.client.config.KubernetesClientConfigMapPropertySource.getData(KubernetesClientConfigMapPropertySource.java:72)
	at org.springframework.cloud.kubernetes.client.config.KubernetesClientConfigMapPropertySource.<init>(KubernetesClientConfigMapPropertySource.java:55)
	at org.springframework.cloud.kubernetes.client.config.KubernetesClientConfigMapPropertySourceLocator.getMapPropertySource(KubernetesClientConfigMapPropertySourceLocator.java:93)
	at org.springframework.cloud.kubernetes.commons.config.ConfigMapPropertySourceLocator.getMapPropertySourceForSingleConfigMap(ConfigMapPropertySourceLocator.java:95)
	at org.springframework.cloud.kubernetes.commons.config.ConfigMapPropertySourceLocator.lambda$locate$0(ConfigMapPropertySourceLocator.java:75)
	at java.base/java.lang.Iterable.forEach(Iterable.java:75)
	at org.springframework.cloud.kubernetes.commons.config.ConfigMapPropertySourceLocator.locate(ConfigMapPropertySourceLocator.java:75)
	at org.springframework.cloud.bootstrap.config.PropertySourceLocator.locateCollection(PropertySourceLocator.java:51)
	at org.springframework.cloud.bootstrap.config.PropertySourceLocator.locateCollection(PropertySourceLocator.java:47)
	at org.springframework.cloud.kubernetes.commons.config.ConfigMapPropertySourceLocator.locateCollection(ConfigMapPropertySourceLocator.java:87)
	at org.springframework.cloud.bootstrap.config.PropertySourceBootstrapConfiguration.initialize(PropertySourceBootstrapConfiguration.java:95)
	at org.springframework.boot.SpringApplication.applyInitializers(SpringApplication.java:613)
	at org.springframework.boot.SpringApplication.prepareContext(SpringApplication.java:381)
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:302)
	at org.springframework.boot.builder.SpringApplicationBuilder.run(SpringApplicationBuilder.java:164)
	at ru.tinkoff.bpm.example.ApplicationKt.main(Application.kt:14)

How can i use starter without explicit clusterrolebindings manifest? Unsuccessfully tried with

    spec:
      serviceAccountName: our_sa
      automountServiceAccountToken: true

In bootstrap.yml:

spring:
  application:
    name: our-ci-example-multi-module-one
  cloud:
    vault:
      enabled: false
    kubernetes:
      reload:
        enabled: true
        mode: event
        strategy: restart_context
      config:
#        sources:
#          - name: ${spring.application.name}-common
#          - name: ${spring.application.name}
        enabled: true
        paths:
          #- { { .Values.application } }-common-config/data.yml
          #- { { .Values.application } }-config/application.yml
          - /etc/${spring.application.name}-common/config/application.yml
          - /etc/${spring.application.name}/config/data.yml
      enabled: true

Mounting configmap like this:

      volumes:
        - name: {{ .Values.application }}-config
          configMap:
            name: {{ .Values.application }}
        - name: {{ .Values.application }}-common-config
          configMap:
            name: {{ .Values.application }}-common
...

          volumeMounts:
            - readOnly: true
              mountPath: /etc/{{ .Values.application }}/config
              name: {{ .Values.application }}-config
            - readOnly: true
              mountPath: /etc/{{ .Values.application }}-common/config
              name: {{ .Values.application }}-common-config
...

Example: Not actual not in our infrastructure.

[CantosSong]

You can create ServiceAccount in advance and then use it.

[pshakhov]

You can create ServiceAccount in advance and then use it.

@CantosSong, but if ServiceAccount resource creating also deprecated in our super-secure-and-managed cluster?

serviceAccountName: our_sa have all permissions for reading, but it seems like application/starter ignores this SA.

[ryanjbaxter]

Why not just mount the configmap in the container and then use spring.config.import to add the configuration? Sounds like the best approach is to not use Spring Cloud Kubernetes at all.

[spring-cloud-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[spring-cloud-issues]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.