TriggerTemplate can't create Secret object

[rannox]

Hello Tekton Triggers Team! Hope you can help me out with that :-)

Expected Behavior

The TriggerTemplate can create a Kubernetes Secret Object.

Actual Behavior

I get the following error message by applying the trigger template resource:
Error from server (BadRequest): error when creating "trigger-template.yaml": admission webhook "validation.webhook.triggers.tekton.dev" denied the request: validation failed: invalid value: no kind "Secret" is registered for version "v1": spec.resourcetemplates[0]

Steps to Reproduce the Problem

1. trigger-template.txt: tekton-triggers.txt
2. kubectl apply -f tekton-triggers.txt

Additional Info

That example is taken from the IBM Tekton tutorial page: IBM Tekton (part "Secure Property" and "Secrets"), where they create a Secret object from the TriggerTemplate.

I am using Tekton Triggers 0.4.0 with Tekton Pipelines 0.12.0 on K8s 1.17.5.

[dibyom]

At the moment we only support creating Tekton resources though being able to create other resources such as Secrets has been proposed (e.g. #482)
/cc @ncskier for the IBM tutorial part

[rannox]

Hello dibyom!

many thanks for the timely reponse! :)
I wrote a java microservice, which gets triggered from the webhook interceptor and creates secrets dynamically.

Just some background info:
For example a developer triggers a prod deployment through the pipeline with his own api key (security requirement for us). The api key is passed as a parameter to the deployment task. This key is unfortunately in clear text in the logs.

It would be nice to have a new type for params, e.g. password param, that isn't shown in clear text in the tekton logs :)

Best regards!

[dibyom]

I wrote a java microservice, which gets triggered from the webhook interceptor and creates secrets dynamically.

Nice!

For example a developer triggers a prod deployment through the pipeline with his own api key (security requirement for us). The api key is passed as a parameter to the deployment task. This key is unfortunately in clear text in the logs.

Interesting. Not sure if this will work for your use case but a workaround I can think of is instead of each developer passing the apiKey as a param, they could pass a ref to a Secret name that contains the apiKey

It would be nice to have a new type for params, e.g. password param, that isn't shown in clear text in the tekton logs :)

Would this be in Triggers/Pipelines or both?

[jlpettersson]

For example a developer triggers a prod deployment through the pipeline with his own api key (security requirement for us). The api key is passed as a parameter to the deployment task. This key is unfortunately in clear text in the logs.

It would be nice to have a new type for params, e.g. password param, that isn't shown in clear text in the tekton logs :)

Interesting use-case.

I am not sure writing the key to a Secret is a good option for this use-case. Secrets must have unique name, you want to refer to it later. And there must be a way to garbage-collect or remove the Secret at some point. Secrets is usually not used in that dynamic context. Secrets in a namespace should probably be owned by the owners of the namespace.

I understand that you want to authenticate the request to the Trigger. That should be supported.

Can you describe how you want to use the api-key later in the Pipeline, I am not sure I fully understand your use-case. Is it an api-key intended for some other system than the Trigger?

A possible solution, as it currently is implemented is that you create a service that receives the request with the api-key, and then triggers (on behalf of the user) the Trigger, then you can have a Task and lookup the secret from a reference passed in a param.

[rannox]

Sorry for the late anwser!

I understand that you want to authenticate the request to the Trigger. That should be supported.

Yeah, that would be nice!

A possible solution, as it currently is implemented is that you create a service that receives the request with the api-key, and then triggers (on behalf of the user) the Trigger, then you can have a Task and lookup the secret from a reference passed in a param.

I think our current solution matches the one you just described. I will try to explain a bit the use case, and the current implementation, hopefully it will understandable :)

We have applications decomposed in bounded contexts.
Each bounded context is managed by one team and can have one or more microservices.
Furthermore each team implements their own CI (e.g. in Jenkins, Tekton, etc) pipeline:

The CD Pipeline is implemented in Tekton from a centralized team and deployed in every bounded context in a [bounded-context]-cd-pipeline-namespace.
Tha Tasks of an example CD pipeline look something like that:

1. checkout
2. build image
3. validations
4. ...
5. deploy (via kubectl --token [personal api-key]")
6. cleanup

Team members of a bounded context must be able to deploy their microservices with their own personal api-key using the CD.

So we are deploying the EventListener, TriggerBinding, TriggerTemplate and the Pipeline CRD in each of these [bounded-context]-cd-pipeline-namespaces.
The Tasks that are referenced in the Pipeline CRD are from Kind ClusterTasks.

The current workflow looks like this:

1. A developer triggers the pipeline through a HTTP Request to https://cluster/[bounded-context]-cd-pipeline
   • The HTTP Request contains the api-key and the URL to the deployment manifest
2. The EventListener forwards the HTTP Request using the Webhook Interceptor to a microservice, which
   • extracts the api-key from the HTTP Request
   • creates a Secret Object (on behalf of the user) in the [bounded-context]-cd-pipeline-namespace with a random name
   • returns the name (e.g. generated-secret-[someID]) of the Secret Object to the
     TriggerTemplate
   • The TriggerTemplate creates the PipelineRun by passing the name of the Secret in a param:

apiVersion: triggers.tekton.dev/v1alpha1
kind: TriggerTemplate
metadata:
  name: [bounded-context]-trigger-template
  namespace: [bounded-context]-cd-pipeline-namespace
spec:
  params:
  - name: generatedSecretName
    description: generated secret
  resourcetemplates:
  - apiVersion: tekton.dev/v1beta1
    kind: PipelineRun
    metadata:
      generateName: cd-pipeline-run-
      namespace: [bounded-context]-cd-pipeline-namespace
    spec:
      ...
      pipelineRef:
        name: [bounded-context]-cd-pipeline-crd
      params:
      - name: generatedSecretName
        value: $(params.generatedSecretName)

3. The Task "deploy" in the Pipeline uses the generated Secret Object for the microservice deployment:

   - name: API_KEY
       valueFrom:
          secretKeyRef:
            name: $(params.generatedSecretName)
            key: secret_key

4. The Task "cleanup" in the Pipeline deletes the generated Secret Object from the cluster

[jlpettersson]

@rannox thanks for a good description of the use case!

I am working on a very similar setup.

5. deploy (via kubectl --token [personal api-key]")

I wouldn't call this an API-key, isn't this a ServiceAccount Token with access to the control plane?

The way I solve it, in my solution that is very similar, is that when I generate the namespace [bounded-context]-cd-pipeline-namespace I also generate the Service Account, e.g. stage-deployment-account in that namespace, and set appropriate RBAC permissions. Then I use that Service Account token when doing kubectl --token [service-account-token]

In my case, the step:

A developer triggers the pipeline through a HTTP Request to https://cluster/[bounded-context]-cd-pipeline

is happening when a developer do git-push to a git-repository. And I have already setup an authenticated connection between the git-repository and the Trigger with authentication.

Is that a setup that would work for you as well?

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.