SECURESIGN-1014 | Add support for Trusted Timestamp Authorities in SecureSign

[JasonPowr]

Opening this as a draft pr, so far this is just the basic deployment of the Timestamp Authority. just looking for some feedback. jira: https://issues.redhat.com/browse/SECURESIGN-1014

Testing

1. Build and deploy operator
2. TSA should come up with the rest of the stack
3. Sign an image with the flag --timestamp-server-url=$TSA_URL eg

TSA_URL=https://<tsa-url>/api/v1/timestamp
cosign sign -y --timestamp-server-url=$TSA_URL <image>

4. To verify the timestamp you need to retrieve the certificate chain using curl https://<tsa-url>/api/v1/timestamp/certchain > ts_chain.pem, then run the cosign verify cmd like so:

cosign verify --timestamp-certificate-chain=ts_chain_local.pem <image>

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JasonPowr

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [JasonPowr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[JasonPowr]

/test tas-operator-e2e

[JasonPowr]

/test tas-operator-e2e

[JasonPowr]

/test tas-operator-e2e

[bouskaJ]

Is there anything common we can share with Rekor ? Both components generate signer with all related keys.... See https://github.com/securesign/secure-sign-operator/blob/main/internal/controller/rekor/actions/server/generate_signer.go#L200

[JasonPowr]

Ill take a look thanks for the review :)

[osmman]

The current implementation of the TSA API looks good overall.

However, I would like to request some additional changes to ensure thorough testing and integration. Firstly, please add multiple unit tests for the TSA component, focusing specifically on the generateSigner and ntpMonitoringAction actions. Our experience shows that most bugs in our operator stem from user modify values in spec, and having robust unit tests for these actions will help mitigate this issue.

Additionally, extend the current controller tests to verify that objects and resources are correctly generated. Alongside this, please create a new test case to cover the hot update scenario, ensuring that the controller handles this situation appropriately.

Lastly, modify our end-to-end (e2e) tests to integrate the new TSA component, with a particular focus on upgrade testing.

[osmman]

Currently I am slowly changing behavior when we should not deleting generated secrets by our operator. The reason is to keep them in cluster for key rotation and enable to users find them for validated old signed data.

So you need to modify this action:

• by removing controllerutil.SetControllerReference and g.Client.DeleteAllOf
• solving remove TSACertCaLabel from old secrets, is is required other wise Tuf controller will fail on error of multiple secrets. You can find inspiration in Rekor component
• create unit tests for this action

[osmman]

it is better to use immutable configmaps, the main reason is change of cfg will automatically force deployment to apply new config. You can use kubernetes.CreateImmutableConfigmap function

[JasonPowr]

Thanks Tomas appreciate the review :)