Integrations: web API and tctl

[marcoandredinis]

This PR adds end user interface to manage integrations:

tctl

$ tctl get integrations --config teleport.yaml --format text
Name        Type     Spec                                           
----------- -------- ---------------------------------------------- 
myawsint    aws-oidc RoleARN=arn:aws:iam::123456789012:role/DevTeam 
mynewawsint aws-oidc RoleARN=arn:aws:iam::123456789012:role/OpsTea

HTTP API

$ curl 'https://127.0.0.1.nip.io:3080/v1/webapi/sites/lenix/integrations'

{
  "items": [
    {
      "name": "myawsint",
      "subKind": "aws-oidc",
      "awsOIDC": {
        "roleARN": "arn:aws:iam::123456789012:role/DevTeam"
      }
    },
    {
      "name": "mynewawsint",
      "subKind": "aws-oidc",
      "awsOIDC": {
        "roleARN": "arn:aws:iam::123456789012:role/OpsTeam"
      }
    }
  ],
  "nextKey": ""
}

part of RFD #22556

[github-advanced-security]

You have successfully added a new Trivy configuration .github/workflows/trivy.yaml:trivy. As part of the setup process, we have scanned this repository and found no existing alerts. In the future, you will see all code scanning alerts on the repository Security tab.

[marcoandredinis]

Opening this PR for review because the base branch is approved
#24133
(I'm just fighting with some flaky tests to get it merged)

[r0mant]

Can this logic be encapsulated into a CanUpdate() method on the integration resource? So it can be used by other clients as well, e.g. tctl will also need it, right? Check out a similar method on the trusted cluster resource.

[marcoandredinis]

I was able to apply that pattern to tctl but not here

We are using a type specific to Web.
To re-use the CanChangeStateTo here, we would need to re-create the integration to then pass it to the existing integration's CanChangeStateTo.

I think we should keep this if here.

Let me know what you think 🙏

[r0mant]

Hmm do we really have "subkind_spec" field in the resource or is it just some test artifact? Why can't we just do

spec:
  aws_oidc:
    role_arn: ...
  somethin_else:
    ...

None of other resources had subkind_spec e.g. check out ProvisionToken, it also has a bunch of fields for different integrations (Github, AWS, etc.) and they're not nested under anything.

[marcoandredinis]

Integration resource uses the OneOf definition (it was suggested here #23553 (comment) )
So, when we MarshalJSON it comes with the OneOf type as a key:

{
    "kind": "integration",
    "sub_kind": "aws-oidc",
    "version": "v1",
    "metadata": {
        "name": "some-integration"
    },
    "spec": {
        "subkind_spec": {
            "aws_oidc": {
                "role_arn": "arn:aws:iam::123456789012:role/DevTeams"
            }
        }
    }
}

I can customize the Un/MarshalJSON to "hide" the subkind_spec, but I would rather not add more custom code

Let me know if you still think we should remove that extra field and I will remove it 👍

[r0mant]

If this was a non-user-facing resource, it wouldn't have mattered much but because users will have to create it the extra subkind_spec field just adds extra noise IMO.

With this structure we'd still have spec.subkind_spec.aws_oidc, spec.subkind_spec.gcp_xxx and so on, I don't really see how it's better than just spec.aws_oidc, spec.gcp_xxx, etc.

I agree we shouldn't just stuff all fields for all integrations in the integration's spec intermixed (that was main @rosstimothy's concern as I understood), but having separate sub-fields for different integrations like we have for provision tokens for example would make it easy to see which parameters are for which integration without extra noise.

Or I think you can keep using oneof but apply it to the whole spec? Something like this should work:

message IntegrationV1 {
  ResourceHeader Header = 1 [...];
  oneof Spec {
    AWSOIDCSpecV1 AWSOIDC = 2 [...];
    // Other integrations will go here
  }
}

Have you tried this?

[marcoandredinis]

Or I think you can keep using oneof but apply it to the whole spec?

I was trying to leave room for common properties
Things like status.

I'll change the serializers, that should be enough to get a better operator experience 👍

[zmb3]

Please fix the tclt typo in the commit message before merging.

[zmb3]

Looks better as long as we update the godoc to match implementation

[public-teleport-github-review-bot]

@marcoandredinis See the table below for backport results.

Branch	Result
branch/v12	Failed