stackitcloud
Feature Request: Support CLI Authentication Fallback in the STACKIT Terraform Provider
Description
It would be highly beneficial if the STACKIT Terraform Provider could automatically fall back to an active stackit CLI authentication session. This would allow users to authenticate via the stackit CLI and seamlessly use Terraform locally, without requiring additional manual authentication steps.
Current Workaround
At the moment, this behavior can be manually achieved by retrieving an access token via the CLI and exporting it as an environment variable:
stackit auth login
export STACKIT_SERVICE_ACCOUNT_TOKEN=$(stackit auth get-access-token 2>/dev/stdout)
terraform init && terraform apply
Proposed Enhancement
Enable the Terraform provider to detect and utilize the existing CLI session automatically, similar to how other cloud providers (e.g., Azure CLI, AWS CLI) handle authentication fallback in their Terraform providers. This would greatly improve the developer experience and streamline local workflows.
We already talked about this internally! It is in our backlog. Keep in mind it is STACKIT not StackIT :-P
It should work since 0.47.0 - I could confirm it locally.
In https://github.com/stackitcloud/terraform-provider-stackit/pull/745, the sdk core package was bumped to v0.16.2 which includes https://github.com/stackitcloud/stackit-sdk-go/pull/1499
Hello @rswrz,
we created a RFC #880 with our target architecture of this feature and we will start to implement it in the next weeks.
Love this. Makes your cloud so more a viable alternative for the big folks. Decent, integrated, audittrailed, operations using personal IDs instead of a generic service account.
Like the proposal in #880, and tbh you should consider already documenting @rswrz 's workaround. It does what it needs to do with a simple shell alias.
(although @rswrz's solution is barely usable given the extremely short lifetime of the token)
We'd greatly appreciate this feature. Using the stackit CLI with a personal account in Terraform significantly improves project audit logs by showing the actual user instead of a generic service account. So besides being a very convenient feature, it would also increase the security of the platform.
Hi Stackit team. Could you share some insights on how this RFC would progress and what the timelines would be? From a security perspective, we want to limit the number of long-lived tokens for service-accounts as much as possible, want to have the user show up correctly in the audit logs.
The current workaround by @rswrz works, but just barely, as it times out soo quickly (eg: changing a nodepool never "completes" because the token is expired by the time the operation has been completed 100%.
Hi @franklouwers, Unfortunately we have been busy with some other topics in the last weeks and couldn't make any progress on the CLI authentication. I'll try to prioritize this in our internal backlog, as this is a highly requested feature.
Best regards, Marcel
Hi Team, we are also still highly interested in this feature. We will soon start our migration to STACKIT and I would like to avoid creating a service account for everyone who wants to run terraform locally. Can you give an update, or let us know if there is anything we can support you with?
Hi,
we have the CLI Authentication still in our Backlog. So the implementation is still planned, but at the moment I can't say when we will start with it, because of some other prioritizations.
We are open for contributions and can support you within them.
In the meanwhile a workaround to already use the token from the CLI in Terraform is, to store the token from the CLI in the STACKIT_SERVICE_ACCOUNT_TOKEN environment var, like suggested in the description of this issue by @rswrz.
stackit auth login export STACKIT_SERVICE_ACCOUNT_TOKEN=$(stackit auth get-access-token 2>/dev/stdout) terraform init && terraform apply
Best regards, Marcel from the STACKIT Developer Tools Team
The problem is these tokens are very short lived (900s). Which means that for large terraform operations, the run might stop half-way. Or that your first run would succeed but your second would fail. If we'd be able to get longer lived tokens (eg 10 hours so they are guaranteed to last at least 1 working day), that would solve the problem for now.
This is an api limitation and we can't change how long the token is valid. It's also for security reason a short lived token so this will not change in the future.
So if you just want to execute $ terraform plan or if you have a small terraform operation, the workaround should work. But for longer operations we would need the implementation from the RFC, which would have access to the refresh token and can execute with it, longer terraform operations.
This is an api limitation and we can't change how long the token is valid. It's also for security reason a short lived token so this will not change in the future.
The browser-token is valid for a very long time (multiple days), so a non-interactive (!!!) stackit auth login would auto-login without any "proof" besides starting the browser which previously authenticated. (Or read it from the browser's cookie jar)
Could you discuss this with the security team and re-evaluate please?
The browser-token is valid for a very long time (multiple days), so a non-interactive (!!!)
stackit auth loginwould auto-login without any "proof" besides starting the browser which previously authenticated. (Or read it from the browser's cookie jar)
@franklouwers Thanks for reporting this. I created a ticket in our backlog and we will adjust this soon
The browser-token is valid for a very long time (multiple days), so a non-interactive (!!!)
stackit auth loginwould auto-login without any "proof" besides starting the browser which previously authenticated
That's only partially truth. The browser-token is a session more that a token. It's not useful if you use it alone as it only works for request a token and it implies some security measures in place.
Could you discuss this with the security team and re-evaluate please?
The token expiration is fixed and this won't be changed AFAIK, the suggested approach is using refresh tokens to get new access tokens during a longer time.
This PR limits the user session to 12h in the cli but also when the user has to be logged again
