Use single-namespace Korifi Helm chart

[vkazmin1]

Hi team,

As we know, Korifi Helm by default creates resources in different namespaces, such as korifi, korifi-gateway or whatever we set as a base namespace in Helm values.yaml

Problem

Korifi deployment under ArgoCD displays OutOfSync state if we do not specify target namespace in ArgoCD Application such as

  destination:
    server: https://kubernetes.default.svc
     namespace: korifi

And vice versa, if we specify target namespace, ArgoCD installs all Helm resources into the target namespace (korifi).

Next, we deploy contour for korifi. Some contour resources run in korifi-gateway namespace, but since we do not declare target namespace in Korifi ArgoCD Application, it doesn't expect to have external resources and complains about desync. It doesn't break anything, we just can't get "all good" state and therefore it's annoying.

Question

The question is - is it critical to apply korifi Ingress, Gateway and ConfigMap in {{ .Release.Namespace }}-gateway (that's what we have in Korifi Helm chart) or we can simply install entire Helm chart in the single namespace avoiding conflicts on korifi level? I'm just not aware if it can break smth inside korifi logic / CRDs level.

[danail-branekov]

As far as I remember, we decided to use korifi-gateway namespace for the gateway as the deployment contour creates for the gateway required certain capabilities that are incompatible with the restricted pod security standard we use for the korifi namespace.

Back in time using a dedicated namespace with less tight restrictions seemed like a good compromise of not extending the permissions on the korifi namespace.

But if using two namespaces causes more issues than it solves, we could consider relaxing the korifi namespace pod security labels so that the gateway can live in the korifi namespace as well.

[vkazmin1]

As far as I remember, we decided to use korifi-gateway namespace for the gateway as the deployment contour creates for the gateway required certain capabilities that are incompatible with the restricted pod security standard we use for the korifi namespace.

Back in time using a dedicated namespace with less tight restrictions seemed like a good compromise of not extending the permissions on the korifi namespace.

But if using two namespaces causes more issues than it solves, we could consider relaxing the korifi namespace pod security labels so that the gateway can live in the korifi namespace as well.

I assume it would be enough to just have a possibility to disable restricted labels on korifi namespace via values.yaml
Smth like

appNamespace:
  restricted: false # true by default
# Description: ...

[danail-branekov]

I assume it would be enough to just have a possibility to disable restricted labels on korifi namespace via values.yaml

Honestly, I am not sure whether such a value is worth the complexity it brings. @georgethebeatle @uzabanov what do you think?

[georgethebeatle]

Right now creating the korifi and cf namespaces are responsibility of the operators, which means that their level of security is determined by them. Then when running helm install both namespaces are passed as parameters. Introducing a helm value to control the security level of the korifi namespace would take this control away.

What if we introduced korifiGatewayNamespace value instead and defaulted it to korifi-gateway? This will be backwards compatible and will let anyone specify a different namespace for the gateway resources, i.e. the korifi namespace itself. Given that the pod security policy is determined by the operators, they should be able to set it according to their needs, i.e. set it to baseline or even privileged and reuse korifi as the gateway namespace. I think this should resolve the ArgoCD problem stated above. What do you think @vkazmin1 ?

One additional remark is that such a change will not be 100% backwards compatible. Suppose that an operator installed korifi in a korifi-staging namespace instead of the conventional korifi namespace. Then when they upgrade they will have to explicitly pass gatewayNamespace=korifi-staging-gateway to remain backwards compatible. Having said that, I don't think that there will be many people who did that and if we mention it in the release notes we should be fine.

[vkazmin1]

What if we introduced korifiGatewayNamespace value instead and defaulted it to korifi-gateway? This will be backwards compatible and will let anyone specify a different namespace for the gateway resources, i.e. the korifi namespace itself. Given that the pod security policy is determined by the operators, they should be able to set it according to their needs, i.e. set it to baseline or even privileged and reuse korifi as the gateway namespace. I think this should resolve the ArgoCD problem stated above. What do you think @vkazmin1 ?

I think it's a good idea. You are right that people have to be aware of such changes in order to avoid issues on the upcoming update due to the new namespace values introduction, otherwise it will be broken.

The concept in general is fine and brings us more flexibility, so I like it.

If this approach is agreed with the rest of the team, I can prepare the PR.

[danail-branekov]

+1

[danail-branekov]

@vkazmin1 please go ahead with PRing the new helm value korifiGatewayNamespace. Keep the following in mind:

• the new value should default to korifi-gateway for backwards compatibility
• the operator is responsible to create that namespace in advance, similarly to the korifi and cf namespaces. Make sure to update the install guide accordingly
• If the namespace does not exist, the helm chart should fail (i.e. it should not be created by the chart)

In the release notes we will add a "breaking change" section to point the new behaviour out.

[vkazmin1]

Hi @danail-branekov and @georgethebeatle
I prepared the PR: #4214