Change existing AWS service connection authentication from access & secret key to OIDC

[swansonaj]

Is your feature request related to a problem? Please describe.
I tried to modify an existing AWS service connection to switch from access & secret key authentication to OIDC authentication. Using the service connection editor I cleared the access key and checked the "Use OIDC" checkbox (note that I could do nothing with the secret key because it is already empty according to the UI). I then re-ran a pipeline that was using the service connection and received this error:

"##[error]Error: Need to define or omit both "Access Key ID" and "Secret Access Key", not just one."

I strongly suspect this is because I was only able to clear the access key field while the secret key remained unchanged.

Describe the solution you'd like
It would be very helpful if the service connection UI had some technique for clearing the secret key or if the runtime just logged a message that OIDC authentication is being used because incomplete access key/secret key credentials were configured in the service connection.

Describe alternatives you've considered
I considered asking customers to create a new service connection that uses OIDC but then they also have to modify all of their pipelines to use the new service connection. It would be much easier if I could provide instructions to them on how to modify their existing service connections.

Additional context
Organizationally, I work for group that sets standards for our whole enterprise so I am looking for the most efficient way to convert our whole enterprise to use OIDC for AWS service connections.

[shillam]

@swansonaj did you ever find any workaround to clear this? We are looking to do the same switch to using OIDC

[ROunofF]

Unfortunately the UI to edit this isn't something add-ons controls... Looks like they are treating the "empty" field on the secret as don't change it...

I wonder if there is programmatically a way to clean the secret ?

Otherwise, recreating it could potentially be the only options :(

[swansonaj]

@swansonaj did you ever find any workaround to clear this? We are looking to do the same switch to using OIDC

No workaround to date

[swansonaj]

Unfortunately the UI to edit this isn't something add-ons controls... Looks like they are treating the "empty" field on the secret as don't change it...

I wonder if there is programmatically a way to clean the secret ?

Otherwise, recreating it could potentially be the only options :(

Thanks for checking. Since the UI path is a dead end could you consider the other suggestion I made as I do think it is under control of this add-on:

"or if the runtime just logged a message that OIDC authentication is being used because incomplete access key/secret key credentials were configured in the service connection."

In other words why do you have to "omit" both the access key AND secret key in order for OIDC to be used. Imo, its pretty obvious that OIDC is the desired authentication if the access key is omitted and the OIDC flag is checked.

[ROunofF]

I just did a test and it seems you can remove those fields via the az tool (or API), this may be a viable approach...

Anyway, I had issue getting my first PUT to work but I was able to do a get and set the value to an empty string "":

# Get the endpoints json 
az devops invoke --http-method GET --area service-endpoints --organization https://contoso.visualstudio.com/ --area serviceendpoint --resource endpoints --api-version 7.1 --route-parameters project=Test endpointId=XYZ-XYZ-XYZ —out-file endpoint.json

# Set username and password empty
cat endpoints.json | jq '.authorization.parameters.password |= "" | .authorization.parameters.username |= ""' > endpoints_cleaned.json

# Put to update the service connections
az devops invoke --http-method PUT --area service-endpoints --organization https://contoso.visualstudio.com --area serviceendpoint --resource endpoints --api-version 7.1 --route-parameters endpointId=XYZ-XYZ-XYZ  --in-file endpoints_cleaned.json