Enhancement: Introduce new query parameter for `jsonKey` to enable common use case

[jfisheratwork]

Enhancement to provide for common use case looking for a specific key (password) out of the secret payload

Often though many different pieces of data are in the Secret Manager JSON payload the data the application is interested in is simply the password or secret at hand.

Look to add parity similar to how it works when retrieving directly from ECS/task definition

Implementation details/concerns:

• As the payload would change should it be a different end point or just an additional query param?
• What type of validation and error codes would be needed for when json key is not present?

Option 1:
Add a new simple query parameter
http://localhost:2773/secretsmanager/get?secretId=<YOUR_SECRET_ID>&jsonKey=password

(Less Ideal) Resulting payload BAU with new response key SecretKeyValue

{
    "ARN": "arn:aws:secretsmanager:us-west-2:123456789012:secret:MyTestSecret-a1b2c3",
    "Name": "MyTestSecret",
    "VersionId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
    "SecretString": "{\"username\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}",
    "SecretKeyValue": "EXAMPLE-PASSWORD"
    "VersionStages": [
        "AWSCURRENT"
    ],
    "CreatedDate": 1523477145.713
}

(More Ideal) Resulting payload that breaks the contract of original query response

EXAMPLE-PASSWORD

Option 2:
Introduce a different endpoint to allow for different payload

http://localhost:2773/secretsmanager/<YOUR_SECRET_ID>/password

Resulting payload

EXAMPLE-PASSWORD

I am open to trying to help contribute if issue is excepted

[simonmarty]

Having each consumer of the agent have to do additional work to parse json and retrieve is error prone.

Do you have examples of situations where this is error prone? jq/language specific JSON libraries are trivial to use. I worry this would pollute the agent API unnecessarily.

[jfisheratwork]

The observation I was making was more related to trying to provide for a common use case.

Often though many different pieces of data are in the Secret Manager JSON payload the data the application is interested in is simply the password or secret at hand.

When looking at the way AWS ECS provided for injecting secrets I really appreciated they added the ability to specify a query including the json key

arn:aws:secretsmanager:region:aws_account_id:secret:secret-name:json-key:version-stage:version-id

So in this case its not so much about trying avoid an error or use of JSON library within the application but instead looking to provide a way that more succinctly allows the application to request exactly what it is looking for.