Having placeholder to targeted namespace in Template about kiosk

[FabianKramm]

@LuisPiedra @allamand this is now possible with kiosk v0.2.0:

apiVersion: config.kiosk.sh/v1alpha1
kind: Template
metadata:
  name: space-template
resources:
  manifests:
  - apiVersion: rbac.authorization.k8s.io/v1beta1
    kind: RoleBinding
    metadata:
      name: utils-admin-dev-space3
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: cluster-admin
    subjects:
    - kind: ServiceAccount
      name: utils-admin
      namespace: '${NAMESPACE}'

[FabianKramm]

@allamand thanks for opening this issue! I see the use case, however it is usually not a good idea to create cluster scoped objects via the template like ClusterRoleBinding, because multiple templateinstances will create conflicts with overriding the existing objects. It is possible to do that, however it is not encouraged. The idea of templates is to specify namespace scoped resources that will enforce some sort of restriction for a newly created space and kiosk ensures the template instances are created during space creation.

I think in your use case it would be better to use a RoleBinding that only grants namespace access to a ServiceAccount and here you wouldn't need a namespace identifier:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: test
subjects:
- kind: ServiceAccount
  name: utils-admin
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io

In general, I think we can consider something like this, however I think we have to solve the bigger problem of how to avoid conflicts with cluster scoped resources in templates first.

[allamand]

This make sense. Thanks

[LuisPiedra]

Hi,

I have the same need but for a different use case. In my case, I would like con configure Ingress for a Service that is started as part of the template, which is namespaced resource, but of course I cannot have the same URL in different namespaces.

I guess I could give up on the idea of starting workloads as part of the TemplateInstance, as its intention seems to be for limiting the activity on the space rather than providing capabilities in the Space from scratch. Anyway, a Template that cannot use placeholders is a really weird template :)

[FabianKramm]

@LuisPiedra I see, yes I agree we should add capabilities in kiosk to parameterize a template. Our current idea is that we could add something like openshift does and add a parameters section to a template definition:

kind: Template
apiVersion: v1alpha1.tenancy.kiosk.sh
metadata:
  name: my-template
resources:
  manifests:
  - kind: BuildConfig
    apiVersion: v1
    metadata:
      name: cakephp-mysql-example
      annotations:
        description: Defines how to build the application
    spec:
      source:
        type: Git
        git:
          uri: "${SOURCE_REPOSITORY_URL}" 
          ref: "${SOURCE_REPOSITORY_REF}"
        contextDir: "${CONTEXT_DIR}"
  - kind: DeploymentConfig
    apiVersion: v1
    metadata:
      name: frontend
    spec:
      replicas: "${{REPLICA_COUNT}}"
parameters:
  - name: SOURCE_REPOSITORY_URL 
    value: https://github.com/sclorg/cakephp-ex.git 
    required: true 
  - name: GITHUB_WEBHOOK_SECRET
    validationRegEx: "[a-zA-Z0-9]{40}" 
  - name: REPLICA_COUNT
    value: "2"
    required: true

With that approach we could also add something like pre-defined parameters which could be namespace the template got initiated in and owner account name for example.

Then we would also add a parameters section to TemplateInstance which would allow you to use these self created parameters. These additions should also solve your problem and will make kiosk templates finally a real template :).

[LuisPiedra]

This is cool @FabianKramm

I finally addressed my issue by using Helm chart, as the namespace can be resolved in Helm template with {{ .Release.Namespace }}, but I'm sure templating directly in the Kiosk template will come handy at some point.