Kubernetes extension: Configure additional role policies for generation

[heubeck]

Description

The Kubernetes extension generates a ClusterRole based on the requirements of the Deployment (ConfigMap, Secret, CRD access...).

When building operators, there may be additional policies required. I propose to make them configurable, and would like to contribute this enhancement.

Implementation ideas

Add a new @ConfigGroup list item to the KubernetesConfig and OpenshiftConfig containing basically the same like

    /**
     * Corresponds directly to the Kubernetes {@code PolicyRule} resource.
     */
    public static final class PolicyRule {
        private final List<String> apiGroups;
        private final List<String> nonResourceURLs;
        private final List<String> resourceNames;
        private final List<String> resources;
        private final List<String> verbs;

Configuration will become a little ugly, maybe there's a better approach:

quarkus.kubernetes.policies[0].api-groups=extensions,apps
quarkus.kubernetes.policies[0].resources=deployments,deployments/status
quarkus.kubernetes.policies[0].verbs=get,watch,list
quarkus.kubernetes.policies[1].cluster-wide=true
quarkus.kubernetes.policies[1].api-groups=apiextensions.k8s.io
quarkus.kubernetes.policies[1].resources=customresourcedefinitions
quarkus.kubernetes.policies[1].verbs=get,update

@iocanel WDYT?

[quarkus-bot[bot]]

/cc @geoand, @iocanel

[heubeck]

Started with some experiments, currently failing with

Failed to execute goal io.quarkus:quarkus-maven-plugin:999-SNAPSHOT:build (default) on project kubernetes-docker-build-and-deploy-statefulset: Failed to build quarkus application: java.lang.IllegalArgumentException: SRCFG00013: No Converter registered for class io.quarkus.kubernetes.deployment.RolePolicyConfig

How to register a converter for the new config group?

[geoand]

You don't have to. If you use the proper Quarkus extension configuration annotations (as for the example the KubernetesConfig and its members use), you won't have that issue

[heubeck]

Thank you @geoand, figured it out:

@ConfigItem
List<ComplexConfigGroupType>

doesn't work, whereas

@ConfigItem
Map<String, ComplexConfigGroupType>

works fine. Even if for my issue no key is required, it's probably not worse than indexed properties.

[heubeck]

Ok, I'm done with the vanilla Kubernetes implementation proposal in a forked repo PR. As this one is build on top of my StatefulSet enhancement, I'll created the roles/policies enhancement PR, after the StatefulSet is merged.

If you agree with the implementation, I will complete the Openshift part.

[geoand]

Best open a draft PR on Quarkus so @iocanel can have a look and comment on the implementation

[heubeck]

Best open a draft PR on Quarkus so @iocanel can have a look and comment on the implementation

As you wish: https://github.com/quarkusio/quarkus/pull/21595 ;)

Thank you!

[iocanel]

@heubeck

I think that the use of arrays in quarkus configuration is not very common. So, I would also suggest the use of maps. As you mentioned the thing is that there is field in policies that would qualify as an id, but this is no biggie. We have other cases where it happens too.