-
Notifications
You must be signed in to change notification settings - Fork 302
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Local create, Part the First #785
Conversation
$ dep ensure -update github.com/docker/go-units
TODO: fix terrible hack on convertLinuxParameters
These fields have the `yaml:",omitempty"` specification, so they will not be written into the docker compose yaml as long as the values are empty. For many of the ServiceConfig fields, an empty data structure is the same as nil as far as the Marshaller is concerned, so explicitly returning nil on an empty input is unnecessary.
TODO access context to create SSM/SM clients
- Create LocalProject interface, which holds the cli.Context - Acounts for -o flag for specifying custom docker compose file to write to
For the following
Running ecs-cli local create (looks for
If
With output flag:
|
Using
|
Using
|
func (c *secretsManagerClient) GetSecretValue(secretName string) (string, error) { | ||
input := &secretsmanager.GetSecretValueInput{ | ||
SecretId: aws.String(secretName), | ||
VersionStage: aws.String("AWSCURRENT"), // VersionStage defaults to AWSCURRENT if unspecified |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Can we add a comment linking to https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html#API_GetSecretValue_RequestSyntax
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anything in particular that's confusing about this? We don't do this for other wrapped API methods on clients, but happy to make this clearer somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, nothing is confusing. I just had to look it up online to see if they had an explanation for "AWSCURRENT". I like providing a //See <link>
, but it's a nitpick.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that it's the default value, I'm guessing we can probably remove this entirely? I lifted a lot of this code from the Secrets Manager console but i'm wondering now if it's even necessary.
|
||
client := secretsmanager.NewSecretsManagerClient(commandConfig) | ||
|
||
secret, err := client.GetSecretValue(secretName) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dumb question: Is it okay for us to retrieve the value of their secret and output it in a file? Is there some sort of security concern here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The call is tied to their config, so nobody would be able to do this unless they have the customer's creds. No different from how you can display a secret value in the Secrets Manager console. But maybe ping @allisaurus on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I share @efekarakus 's concerns re: outputting the secret contents to the file - I don't think the comparison to the console holds b/c now we are creating something that's persisting on the file system. Is there a way we can set the value as an env var and reference that var in the generated compose file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Writing to env vars and writing to a file aren't really that different from a security perspective -- you could argue writing to an environment variable where other processes might read from it might be worse. One thing that might mitigate this a bit is to change the file permissions to 400 or 600, so only the current user has read/write permissions and no one else does.
In any case, I don't believe there is significant risk, but we could add a log message that says that we'll be pulling and writing the decrypting a secret to the file just to make this more obvious.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense! We'll consult with others offline to discuss what would be the right approach to move forward.
One of the other recommendations suggested by @hencrice is to pass the secrets as environment variables to the docker-compose up
command with local up
. So something like NAME=secret docker-compose -f docker-compose.local.yml up -d
. We'll check if this would be a good approach.
In the mean time to unblock you, what do you think about keeping the client.GetSecretValue as is because it's guaranteed to be used but deleting this function?
Refactored Write to separate IO functionality from main caller, for easier testing
Since this file could potentialy include decrypted secrets, we don't want this to be readable by other users. TODO: allow file permissions to be configurable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly looks good to me, just two questions and the rest are conflicts that can emerge with @iamhopaul123's changes.
arn := p.context.String(flags.TaskDefinitionArnFlag) | ||
filename := p.context.String(flags.TaskDefinitionFileFlag) | ||
|
||
if arn != "" && filename != "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI: @iamhopaul123 is also making modifications for ECS local :) he needed this same logic in local ps
and local down
so it was moved to a function here: https://github.com/aws/amazon-ecs-cli/pull/789/files#diff-d09e4b573b1ca106569f2a8dfcad6cd0R50
} | ||
|
||
if taskDefinition == nil { | ||
return fmt.Errorf("Could not detect valid Task Definition") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: The recommendation for errors is to start with lowercase: https://github.com/golang/go/wiki/CodeReviewComments#error-strings
return config.NewCommandConfig(context, rdwr) | ||
} | ||
|
||
// FIXME: NOTE this will actually read from either ARN or Task Definition family name |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@iamhopaul123 added a new flag for this here: https://github.com/aws/amazon-ecs-cli/pull/789/files#diff-9c07acb4867a9b5d46a004942a378e76R153
|
||
client := secretsmanager.NewSecretsManagerClient(commandConfig) | ||
|
||
secret, err := client.GetSecretValue(secretName) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense! We'll consult with others offline to discuss what would be the right approach to move forward.
One of the other recommendations suggested by @hencrice is to pass the secrets as environment variables to the docker-compose up
command with local up
. So something like NAME=secret docker-compose -f docker-compose.local.yml up -d
. We'll check if this would be a good approach.
In the mean time to unblock you, what do you think about keeping the client.GetSecretValue as is because it's guaranteed to be used but deleting this function?
const ( | ||
LocalOutDefaultFileName = "./docker-compose.local.yml" | ||
LocalOutFileMode = os.FileMode(0644) // Owner=read/write, Other=readonly | ||
LocalInFileName = "./task-definition.json" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was there a reason why we didn't address this comment? :p
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Talked offline, we will address this comment as follow-up: #785 (comment)
Issue #, if available:
Description of changes:
Enter
[N/A]
in the box, if an item is not applicable to your change.Testing
Documentation
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.