feat(oss backend): support aliyun/credentials-go SDK for authentication - #2
Open
twilight-cui wants to merge 2 commits into
Open
feat(oss backend): support aliyun/credentials-go SDK for authentication#2twilight-cui wants to merge 2 commits into
twilight-cui wants to merge 2 commits into
Conversation
Add an opt-in authentication path via the aliyun/credentials-go SDK alongside the existing access_key/assume_role logic, controlled by a new `use_credentials_go` switch and a `credential_type` selector. Supported credential_type values: - access_key - sts - ecs_ram_role - ram_role_arn - oidc_role_arn - credentials_uri - (empty) credentials-go default provider chain All credentials-go invocation is isolated in the new credentials.go so backend.go changes are minimal: a few schema fields and a single if/else branch wrapping the pre-existing ecs_role/assume_role code. region resolution and endpoint/OTS client construction are reused as is.
…ials block
Replace the boolean top-level switch with an opt-in
optional block. When the block is present, the backend
authenticates via the aliyun/credentials-go SDK using the block's fields;
otherwise the traditional access_key / assume_role path is used.
- Move the credentials-go-only fields (credential_type, oidc_provider_arn,
oidc_token_file_path, external_id, credentials_uri, disable_imds_v1)
from top-level into the block, alongside shared fields
(access_key, secret_key, security_token, ecs_role_name, assume_role_*,
sts_endpoint) duplicated for the block.
- Inner fields keep their EnvDefaultFunc, so env-var usage still works once
the block is declared (an empty block triggers the
credentials-go default provider chain).
- configure() now keys off instead of the removed
use_credentials_go bool.
- getCredentialsFromCredentialsGo now takes a map[string]interface{} from
the block rather than a *schema.ResourceData; add getCred* helpers.
- Fix a latent bug: disable_imds_v1 no longer sets both Default and
DefaultFunc (Default would silently shadow DefaultFunc in DefaultValue).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add an opt-in authentication path via the aliyun/credentials-go SDK alongside the existing access_key/assume_role logic, controlled by a new
use_credentials_goswitch and acredential_typeselector.Supported credential_type values:
All credentials-go invocation is isolated in the new credentials.go so backend.go changes are minimal: a few schema fields and a single if/else branch wrapping the pre-existing ecs_role/assume_role code. region resolution and endpoint/OTS client construction are reused as is.
Fixes #
Target Release
1.17.x
Rollback Plan
Changes to Security Controls
Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.
CHANGELOG entry