Skip to content

chore: updating prod template to remove resources and abstract ones #354

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

Merged
merged 7 commits into from
Oct 4, 2021
16 changes: 6 additions & 10 deletions cfn/prod-release.yml
Original file line number Diff line number Diff line change
Expand Up @@ -107,8 +107,7 @@ Resources:
{
"Effect": "Allow",
"Resource": [
"arn:aws:codebuild:${AWS::Region}:${AWS::AccountId}:project/${ProjectName}-test-release",
"arn:aws:codebuild:${AWS::Region}:${AWS::AccountId}:project/${ProjectName}-prod-release",
"arn:aws:codebuild:${AWS::Region}:${AWS::AccountId}:project/${ProjectName}-release-prod",
"arn:aws:codebuild:${AWS::Region}:${AWS::AccountId}:project/${ProjectName}"
],
"Action": [
Expand All @@ -133,10 +132,8 @@ Resources:
"Resource": [
"arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/codebuild/${ProjectName}",
"arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/codebuild/${ProjectName}:*",
"arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/codebuild/${ProjectName}-test-release",
"arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/codebuild/${ProjectName}-test-release:*",
Comment on lines -136 to -137
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you going to make another template for test-release?
There would be much repeated code... I would favor 1 template/stack having both projects as compared to a stack per project.
Then the projects can share policy documents. Otherwise, you would have to repeat your policy documents.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We discussed this offline, but just to document it here. The plan is to have just one project for both test-release and prod-release called release-prod.

"arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/codebuild/${ProjectName}-prod-release",
"arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/codebuild/${ProjectName}-prod-release:*"
"arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/codebuild/${ProjectName}-release-prod",
"arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/codebuild/${ProjectName}-release-prod:*"
],
"Action": [
"logs:CreateLogGroup",
Expand Down Expand Up @@ -176,14 +173,14 @@ Resources:
Type: "AWS::SSM::Parameter"
Properties:
Description: Parameter to store our account id so CodeBuild specs can access it
Name: /CodeBuild/AccountId
Name: /CodeBuild/Account
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These need to match this:

which is /CodeBuild/AccountId

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a little weird, shouldn't this have been caught in the stack creation process? or would this be a case where it would detect a drift. I'll go ahead and change it so they match. The name was causing it to not create the stack, and changing it to Account successfully created the stack.

Copy link
Contributor

@texastony texastony Sep 30, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ohh... then nevermind. The name already exists, right? Because we have been using it.
So... you have a choice... you can figure out where it is defined else where, and remove it, or you can leave it there, and correct the one here.

The only thing is that while /CodeBuild/AccountId is undefined, our release automation will be broken.
Will this effect our CI? Do we use this in our CI? Yes, we do

Here, we have a problem where the CI and release automation (RA) share a resource.

Ok. So... now I have more questions that I hope will lead us to the best outcome.

  1. Do the CI and RA share other resources?
  2. If so, should the CI and RA be created by the same stack?
  3. What creates the CI stack right now?
  4. Finally, is this a case where other libraries also share this resource?

I am sorry to say that I do not know the answer these questions.

Type: String
Value: !Sub "${AWS::AccountId}"
SecretsManagerPolicy:
Type: "AWS::IAM::ManagedPolicy"
Properties:
ManagedPolicyName: !Sub "CryptoTools-SecretsManager-${ProjectName}-release"
Path: /service-role/
Path: "/service-role/"
PolicyDocument: !Sub |
{
"Version": "2012-10-17",
Expand All @@ -192,8 +189,7 @@ Resources:
"Effect": "Allow",
"Resource": [
"arn:aws:secretsmanager:us-west-2:${AWS::AccountId}:secret:Maven-GPG-Keys-GC6h0A",
"arn:aws:secretsmanager:us-west-2:${AWS::AccountId}:secret:Sonatype-Team-Account-0tWvZm",
"arn:aws:secretsmanager:us-west-2:587316601012:secret:Maven-GPG-Keys-Credentials-C0wCzI",
"arn:aws:secretsmanager:us-west-2:${AWS::AccountId}:secret:Sonatype-Team-Account-0tWvZm"
],
"Action": "secretsmanager:GetSecretValue"
}
Expand Down