feat(attestation): federated verification

[migmartri]

This patch adds support for delegated, federated verification during the attestation process.

This means that when an API token is received during attestation, now, in addition to the built-in chainloop authenticator, we can delegate the authN/authZ to a third party service that we already trust.

This feature is configurable via the Helm Chart

2025-02-18T11:34:22.672+0100	INFO	{"component": "jwtMiddleware", "msg": "federated verification enabled, using URL: http://localhost:8002/machine-identity/verify-token"}

Demo: Attestation process using a Gitlab token, there is no difference :)

go run main.go att init --workflow from-gitlab --project chainloop-contrib --replace --version 1.2.3 --release=false
WRN API contacted in insecure mode
INF Attestation initialized! now you can check its status or add materials to it
┌───────────────────────────┬────────────────────────────────────────────┐
│ Initialized At            │ 18 Feb 25 10:34 UTC                        │
├───────────────────────────┼────────────────────────────────────────────┤
│ Attestation ID            │ e8ef6e7d-d9be-48dd-89ca-97862ba5827f       │
│ Organization              │ foobar                                     │
│ Name                      │ from-gitlab                                │
│ Project                   │ chainloop-contrib                          │
│ Version                   │ 1.2.3 (already released)                   │
│ Contract                  │ chainloop-contrib-from-gitlab (revision 1) │
│ Policy violation strategy │ ENFORCED                                   │
└───────────────────────────┴────────────────────────────────────────────┘

You can also provide the --org to the att command if needed

Closes #1817

[javirln]

Is this a leftover?

[migmartri]

No, a logger is now required by the use case

[jiparis]

We might want to make this struct public (in pkg), so that implementors can use it

[jiparis]

I might be missing where the decision is made, but Is this logic called always, no matter if the token belongs to the federated provider?

[migmartri]

That's correct, the federated provider is the one that will figure out if it understands the provided token

[jiparis]

Cannot this be a performance issue? Doesn't it have an issuer claim that can be used to early detect if the token is federated or not?

[migmartri]

It could, but note that this happens after the fact all the other checks have been completed. There is also a cache in place.

What kind of performance issue can you foresee?

[jiparis]

Calling an external URL in every single request to check a token that might be already been processed and understood. Unless I'm missing something, of course.

[javirln]

LGTM!