Parameter Store always defaults to SecureString

[Kazzer]

Many of the strings set in parameter store do not need to be secure strings, and ones that are often are echoed by default.

I think a couple changes might be nice:

• String is the default type
• Strings are echoed
• a flag exists (eg. --encrypt) to upload as SecureString
• SecureStrings are not echoed

[tavisrudd]

By Strings are echoed do you mean that we should echo the input after iidy param set?

[tavisrudd]

@jpb @pauloancheta @rymndhng what do you think about this?

[pauloancheta]

+1 for uploading a non-secure string.
+1 on strings are echoed. It would be nice to have feedback once the parameter has been set. While we shouldn't echo secure strings, we should have a feedback to let the user know that it has been uploaded.

I do like the flag of --encrypt but I'm not so sure about the defaults. I am leaning towards to defaulting to encrypted because people should be more aware that they are uploading a non-secure string.

Having it very easy to upload a non secure string might be a problem for auditing.

[jpb]

It seems to me that the main use-case of using parameter store here is to store things that are secret - if they were not secret then the codebase seems like a better place for them. I feel like this change may be a foot-gun and I fear that changing the behaviour would result secrets being store as plain text in parameter store.

I agree that both echoing secrets and inadvertently storing a secret unencrypted in parameter store are both security concerns, but I feel in this use-case the latter would be a larger problem.

We already have iidy param get --no-decrypt which effectively is a no-echo for SecureString types, and iidy param put --type ... to use String or StringList instead of the default SecureString.

[tavisrudd]

I prefer keeping --type SecureString as the default, especially as AWS have indicated that they're adding support for SecureStrings as an CFN parameter type in the near future.

Which context are we talking about echoing strings? iidy param set doesn't echo anything. iidy param get and related commands decrypt by default.

[Kazzer]

I actually think people should be more cognizant about uploading a secure string. If someone is uploading a password, they should be thinking more about the security of that. It seems like an anti-pattern to have to be "aware" about not securing something versus securing it.

With the echo thing, I was mainly thinking about when the value is being used. Like, if a parameter value is being used somewhere, then any strings should be echoed for visibility by the operator and secure strings should obviously not be echoed (or echo the encrypted value for visibility that a value was used and it was encrypted).

The thing we have to remember with "non-secure" == "in codebase" is they have two completely different authentication protocols. One being GitHub/Git, and the other being IAM. There is a stark difference between the two and I think the statement that strings are to some degree not secrets is categorically false.
For example, something like an AMI ID; it absolutely should not be put in a codebase; it is a secret to GitHub/Git/repo leaks; it is not a secret to IAM users.

Basically:

IAM \ GitHub or Git	not secret	secret
not secret	in codebase	as String in SSM
secret	as SecureString in SSM	as SecureString in SSM

Examples:

• AMI ID, not secret for IAM authenticated users, secret for GitHub users: String in SSM
• application port, not secret for IAM authenticated users, not secret for GitHub users: in codebase
• password for RDS database, secret for IAM authenticated users: SecureString in SSM

Additionally, my bigger issue with SecureString as default is that I as a general IAM user should not have any capability to decrypt SecureStrings. There is absolutely no reason why I should (as part of my day to day) be able to decrypt a database password or the like. If I need that capability, I should have access to a secured role that allows me to do that. Conversely, I absolutely should have the capability to see what queue a service is configured to use or similar.

[Kazzer]

One additional note, if people are adding parameters with password or other secrets that IAM users should generally not be able to decrypt, that would be an education/people problem that needs to be solved. I don't really agree that we should solve people problems with technical decisions that reduce our ability to improve security. (Example being having everyone upload everything as secure strings and then needing allow everyone to decrypt secure strings)

[Kazzer]

cc: @scottbrown (Parameter Store security aspects are being discussed here)