search

crossplane-contrib / provider-gitlab

Crossplane Gitlab provider
Apache License 2.0
57 stars 33 forks source link

Token lifecycle (post Gitlab 16.0 changes) #131

Open somebadcode opened 8 months ago

somebadcode commented 8 months ago

What problem are you facing?

Since the release of Gitlab 16.0, all forms of tokens have a limited life time and they all expire within 1 year and it's not possible to get any longer period than that. Right now, tokens will expire and just be invalid until you replace the resource. Long living tokens is not something that is desirable and having "short" living tokens that are renewed is a more desirable approach.

Me and a co-worker of mine had meetings with Upbound regarding issues like this among other things. Gitlab has a token rotation API endpoint, but using it is the same as revoke+create, which will yield a new token id. The annotation external-name is "immutable" in a sense that updating it is allowed but ignored. So the representative from Upbound came back to us and recommended that managing the tokens (and other time limited resources) as a virtual resources the same way they handle cluster auth for EKS in the AWS provider. Reference: https://github.com/upbound/provider-aws/blob/main/apis/eks/v1beta1/clusterauth_types.go

When it comes to the importing of existing resources, external-name is often used but that can't be used in this case (see prev. paragraph). So they recommended using the relatively new initProvider configuration which is a perfect fit for this. Reference: https://docs.crossplane.io/latest/concepts/managed-resources/#initprovider

Cases:

  1. I currently have a token that is about to expire and I need to manually force a replacement to take place to prevent any issues.
  2. I want to have short living tokens that automatically renew and where I don't need to resort to any manual actions to maintain.

How could Crossplane help solve your problem?

Automatically manage tokens over time, supporting smoother transitions of tokens when they need to be renewed.

I was thinking that we could change the implementation of the tokens and keys to a virtual resource that will be able to keep track of both old and new token during a transition period when tokens are being replaced, and update secrets accordingly. It will not have an external-name but keep track of the relevant tokens using status.

So the question is if the current implementations of the token controllers should adapt to this new behavior in Gitlab 16.0+ or if a virtual resource (no external resource) manages and owns the current implementations.

somebadcode commented 7 months ago

What do you think is the best approach here, @MisterMX and @janwillies ?

I would like to change how tokens are managed sooner rather than later because of how problematic the tokens have become now when they no longer live forever since Gitlab 16.0.

I'd prefer to make the token resources "virtual" in that they aren't directly tied to a specific external resource but it'll manage tokens under the hood and automatically replace tokens when they are about to expire. The tokens will be seen in the status so you can see which tokens that it's currently managing.

The best approach here would be a breaking change so I would really like to have some input on this.

somebadcode commented 7 months ago

I want to have a brief discussion before I start working on this.