Create support for username-password passing without tag value limitations about aws-secrets-manager-credentials-provider-plugin HOT 3 OPEN

Depending on how your AD auth is set up, you may be able to use the new username@domain syntax for the username instead of the DOMAIN\username syntax.

I know this works for general sign-in if your organization uses Azure AD, so I think it should work for what you are trying to do with Checkmarx as well. (I don't know how traditional on-premise AD would behave if given a new-style username.)

Give this a go and let me know if it works

from aws-secrets-manager-credentials-provider-plugin.

Had already tried the @Domain notation. That is allowed in tag value, but Checkmarx doesn't understand it. It probably verifies it against local database as an username looking like email address. In the windows world they often get treated as equivalents, but they are not. The DOMAIN\username is an (older) notation based of NetBios (which can be disabled). Where the username@fqdn domain notation is a UPN notation. Possible to map a user against multiple domains. regardless of this, it would be better to keep the username as a secret from a security perspective. Tags are unencrypted and less protected from prying eyes than secrets. Knowing a valid username is half the battle when you try to brute force access by guessing username-password combinations.

from aws-secrets-manager-credentials-provider-plugin.

It sounds like the first port of call is to raise this with Checkmarx, to get a definitive answer on how Checkmarx handles user@domain usernames. They may well decide that there is a bug that needs fixing. Could you provide more details about which specific Checkmarx products or components you are using with your Jenkins job? (That will indicate whether we need to raise a GitHub Issue on the relevant repo, or send an email to Checkmarx support.)

from aws-secrets-manager-credentials-provider-plugin.