Open ambsw-technology opened 4 years ago
Some additional thoughts:
AuthToken
should use NoEcho
; in that case, exposing the URI exposes secure info.Module
exports strategy.For example, this module could accept a [SSM] ParameterModule
instead of an AuthToken
and export the SSM path at ${RedisModule}-AuthToken
. But I assume you can't chain an !ImportValue
into a dynamic reference.
edit; cfn-modules
might pull something like this off since it could plausibly nest templates so a wrapper extracts the parameter and the nested template resolves it. I think it's literally impossible for aws-cf-templates
to use this pattern without forcing the user to do the unwrapping for it.
I agree, AuthToken
should use NoEcho
. I pushd the change already.
Regarding the connection URL: see #7
It would be even better if we would leverage the secret module instead of AuthToken
as we do here https://github.com/cfn-modules/rds-aurora-serverless/blob/master/module.yml#L194. But I suggest we track this in a separate issue/feature request?
Thanks. The PR will definitely work for us. For the sake of completeness, however, I'll point out that:
TransitEncryption
when you use an AuthToken
and the package captures this corrrectly.The opposite is not technically true so a url like this is valid:
rediss://${ReplicationGroup.PrimaryEndPoint.Address}:${ReplicationGroup.PrimaryEndPoint.Port}'
We're a HIPAA-compliant organization so we must use both. However, I could see this combination being attractive:
TransitEncryption
add no extra management effort and adds some security (e.g. against logging/snooping of network traffic)AuthToken
, the deployer (or code) must, at minimum, generate the AuthToken
(even if passing the URI is now automatic). If you're satisfied with Security Groups for access control, it's an unnecessary hassle.If I understand you correctly you suggest to always use encrypted communication and start the URL with rediss://
, right?
ok... I see. Only if TransitEncryption := true we should use rediss:// ... sorry ... I will fix that
^ exactly.
After one night of sleep I'm not sure if we should Output/Export a secret as a plain text string. That feels wrong to me. If the value is a secret we should threat it that way. Let's see what @andreaswittig adds in #7
In theory I 100% agree. That was what I was trying to say in the second part of my NoEcho comment (emphasis added):
- AuthToken should use NoEcho; in that case, exposing the URI exposes secure info.
But, in practice, how else does cfn-modules
pass information like this to e.g. ECS services? The easiest one is to pass it as environment variable... but then it's plaintext in a different not-NoEcho parameter and you've had to go to all of the trouble to create it outside the RedisModule.
In theory, dynamic references are the "right" way, but they're a design nightmare right now. You have to specify the version of the SSM parameter so they're virtually useless.
Instead of passing ENV variables to my service stack, I could create an SSM parameter in a place that my application picks up, but the behavior isn't really generalizable. In fact, I need to put it in two different places since I have two applications (and, in the future, more) that need to use it.
My bottom line is that this value is going to get passed plaintext somewhere in the current cfn-modules
world. It would be great to develop a standardized (and secure) way to handle these parameters, but this is an acceptable stopgap.
you are right about the dynamic references and SSM parameters. But luckily, you can reference latest if the value comes from Secrets Manager :) I think that's the best way to go. But still, you would need to "construct" the connection string outside of CloudFormation / inside your application based on environment variables.
I was confused how you intended to pass that environment variable to the service without exposing it in e.g. AppEnvironmentKey1Value
(which does not use NoEcho
). I recalled but had never looked into the AppEnvironment1SecretModule
param in CFN modules.
That actually brought me to the documentation for the ECS Container Definition Secrets
key. While CF requires a version number this feature does not e.g.:
"secrets": [{ "name": "environment_variable_name", "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name" }]
So, in theory, the Redis module could construct the entire URI, create a (secure) parameter store entry (avoiding the cost of the Secrets Manager), and expose either (1) the ARN for the secrets module or (2) stack names for one or more secrets modules (e.g. one for just AuthToken and another for the full URI).
Building the URI in an application is virtually unacceptable to me because you need to hard code (or pass) too many values:
When the ECS Service templates only support a half dozen (or fewer) ENV variables, that chews up WAY too many of them.
Nevermind... per the docs,
AWS CloudFormation doesn't support creating a SecureString parameter type.
In theory, a user of Redis will need both the
AuthToken
(if used) and state ofTransitEncryption
to connect. I originally hardcoded some of the values in my template (vs. all of the conditions below), but eventually needed to build a URI like:It seems like this module (and the
aws-cf-templates
equivalent) needs to more aggressively export information. TheAuthToken
is already visible in the parameters and the StackName is pseudorandom so I'm not clear if there's any reason not to build and export the full URI (above). I'd certainly do the same withAuthToken
andTransitEncryption
for consumers who want/need to pass those to the application separately for processing.