[FEATURE] Support access_token based provider authentication

[0x416e746f6e]

Description

It would be great if this provider would directly support access_token authentication mechanism.

This could enable the pattern of using hashicorp vault oauth2 secret-engine to generate short-lived tokens for terraform, so that we don't need to maintain static credentials (on allow them to be remembered inside terraform state-files if they are retrieved via data-source from somewhere).

Affected Resource(s) and/or Data Source(s)

• provider

Potential Terraform Configuration

provider "vault" {
  # ...
}

data "vault_generic_secret" "ovh_auth" {
  path = "secret/oauth2/self/ovh"
}

provider "ovh" {
  access_token = data.vault_generic_secret.ovh_auth.data["access_token"]
}

[amstuta]

Hello @0x416e746f6e, thanks for opening this issue.

This seems like a good idea indeed.
It requires first a patch of the go-ovh library as it doesn't accept directly an access_token today.

We'll work on it whenever possible and keep you posted here !

[0x416e746f6e]

This seems like a good idea indeed. It requires first a patch of the go-ovh library as it doesn't accept directly an access_token today.

We'll work on it whenever possible and keep you posted here !

@amstuta if that helps I have a working patch on my machine. Can send a PR (for both of the repos).

Unfortunately, I am stuck on some strange issue when the access token fails to access /servics path with error:

-----------------------------------------------------
2024/06/02 12:43:11 [DEBUG] OVH API Request Details:
---[ REQUEST ]---------------------------------------
GET /1.0/services/126829131 HTTP/1.1
Host: eu.api.ovh.com
User-Agent: github.com/ovh/go-ovh (Terraform//)
Accept: application/json
Authorization: Bearer REDACTED
Accept-Encoding: gzip


-----------------------------------------------------
2024/06/02 12:43:12 [DEBUG] OVH API Response Details:
---[ RESPONSE ]--------------------------------------
HTTP/1.1 403 Forbidden
Connection: close
Transfer-Encoding: chunked
Access-Control-Allow-Headers: X-Ovh-Timestamp, X-Ovh-Consumer, X-Ovh-Application, X-Ovh-Signature, X-Ovh-Session, Authorization, Content-Type, X-Challenge-Response, X-Challenge-Payload
Access-Control-Allow-Methods: GET, PUT
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: X-Pagination-Cursor-Next, X-Ovh-Queryid
Cache-Control: no-cache, no-store
Content-Type: application/json; charset=utf-8
Date: Sun, 02 Jun 2024 09:43:12 GMT
Server: nginx
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Iplb-Instance: 47056
X-Iplb-Request-Id: 6D268E5B:4447_8D5FBADF:01BB_665C3EAF_13EBF2E6:21AC
X-Ovh-Queryid: EU.ext-3.665c3eb0.2937583.1ebf1c1d2662ca109aa393a127ff342f
X-Xss-Protection: 1; mode=block

50
{
 "class": "Client::Forbidden",
 "message": "You are not allowed to call this route"
}
0

Do you know why could that be? (The underlying client has urn:v1:eu:permissionsGroup:ovh:globalAdmin permission group attached to it).

[amstuta]

Yes you can push a PR first on go-ovh, we'll be happy to review it :)

About the /services endpoint, it is not (yet) restricted by the IAM policies, that's why you get this error.
The solution in the meantime is to use the application key / application secret / consumer key.

[amstuta]

@0x416e746f6e thanks for your contribution on go-ovh, v1.6.0 has been released.