Updating the AWS EC2

[anooptejt]

Adding detailed and correct steps to Configure AWS EC2 with Spinnaker

[dorbin]

I saw your reponse to this before, @anooptejt . Sorry, I'm still not getting it.
What does "miss to add append the line" mean? Do we mean if I choose not to add another managed account to the SpinnakerAssumeRolePolicy section?

Or, under what circumstances exactly would I manually create a policy?

[anooptejt]

This manual Policy we can add it as TroubleShooting. I have noticed clouddriver was not starting up as expected. Hence, i have manually created a policy and checked it out. It worked like a charm. So I would recommend to add this as a Troubleshooting item. Please suggest in case of any other thoughts.

[dorbin]

I'll let @clareliguori weigh in on this, for technical input, then I'll look at the wording. Thanks, @anooptejt!

[clareliguori]

It would be better to have instructions on how to add a new managed account post-stack-creation by adding it to the template in the SpinnakerAssumeRolePolicy section and then updating the existing CloudFormation stack.

[anooptejt]

In the cloudformation template already there is a section to add the SpinnakerAssumeRolePolicy. However, for some weird reason that doesnt make any updates in the AWS. Which is why I have added this section explicitly in the document. Which would make it more easier for users to enable AWS with Spinnaker.

[clareliguori]

Can you provide repro steps where adding a new account to the list in the SpinnakerAssumeRolePolicy section in the template does not cause updates in AWS?

[anooptejt]

Search for SpinnakerAssumeRolePolicy in the managing.yaml
Add the managed account and tried to create the stack using the template. I got SpinnakerAssumeRolePolicy created empty without any of the attributes defined in the template. I had to manually add the #arn in the below format

arn:aws:iam::YOUR_MANAGED_ACCOUNT1:role/spinnakerManaged

[clareliguori]

I tried to reproduce with the following steps, but I wasn't able to - it worked as expected:

# Deploy the stack without updating the template first
$ aws cloudformation deploy \
	--stack-name test-spinnaker-managing-infrastructure-setup \
	--template-file managing.yaml \
	--parameter-overrides UseAccessKeyForAuthentication=true \
	--capabilities CAPABILITY_NAMED_IAM 

# Find the IAM user name
$ aws cloudformation describe-stack-resources \
	--stack-name test-spinnaker-managing-infrastructure-setup \
	--logical-resource-id SpinnakerUser

# Output the provisioned user policy
$ aws iam get-user-policy --policy-name SpinnakerAssumeRolePolicy --user-name test-spinnaker-managing-infrastructu-SpinnakerUser-1V1NBNV5OEEV4
{
    "UserName": "test-spinnaker-managing-infrastructu-SpinnakerUser-1V1NBNV5OEEV4",
    "PolicyName": "SpinnakerAssumeRolePolicy",
    "PolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Action": "sts:AssumeRole",
                "Resource": [
                    "arn:aws:iam::XXXXXXXXXXXX:role/spinnakerManaged"
                ],
                "Effect": "Allow"
            }
        ]
    }
}

# Updated managing.yaml template with new managed account
      PolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Action: sts:AssumeRole
            Effect: Allow
            Resource:
              - !Sub arn:aws:iam::${AWS::AccountId}:role/spinnakerManaged # This is the current account
              - arn:aws:iam::YYYYYYYYYYYY:role/spinnakerManaged # New Managed Account
      PolicyName: SpinnakerAssumeRolePolicy

# Update the stack with the updated template that contains a new managed account
$ aws cloudformation deploy \
	--stack-name test-spinnaker-managing-infrastructure-setup \
	--template-file managing.yaml \
	--parameter-overrides UseAccessKeyForAuthentication=true \
	--capabilities CAPABILITY_NAMED_IAM 

# Output the updated provisioned user policy
$ aws iam get-user-policy --policy-name SpinnakerAssumeRolePolicy --user-name test-spinnaker-managing-infrastructu-SpinnakerUser-1V1NBNV5OEEV4
{
    "UserName": "test-spinnaker-managing-infrastructu-SpinnakerUser-1V1NBNV5OEEV4",
    "PolicyName": "SpinnakerAssumeRolePolicy",
    "PolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Action": "sts:AssumeRole",
                "Resource": [
                    "arn:aws:iam::XXXXXXXXXXXX:role/spinnakerManaged",
                    "arn:aws:iam::YYYYYYYYYYYY:role/spinnakerManaged"
                ],
                "Effect": "Allow"
            }
        ]
    }
}

[clareliguori]

Why does this line get commented out? Is this assuming Spinnaker is deployed on EKS?

[anooptejt]

This is asked to comment because as this Arn is restricting Clouddriver to load AWS account as clouddriver couldnt authenticate AWS Credentials. I have tested these on EKS, AKS, GKE and Vanilla K8s Cluster. Worked Perfectly fine

[clareliguori]

Can you provide the error message you were seeing? I'm not understanding why commenting out an output value in the CloudFormation stack would prevent CloudDriver from loading the account.

[anooptejt]

Apologies if i had caused any confusion here, when i mean comment out. I actually want the 'SpinnakerInstanceProfileArn' to be commented.. I dont have the exception handy right now, i will have to do the setup again.. Need sometime for that

[clareliguori]

I just tried, I believe it's probably this error, which is a bug in the template.

An error occurred (ValidationError) when calling the CreateChangeSet operation: Unresolved resource dependencies [SpinnakerInstanceProfile] in the Outputs block of the template

@dorbin I know at some point, the template source was in this github repo, and at some point it was taken out and replaced by a CloudFront link (#926). I'm not sure what the reasoning was, but ideally the community would be able to own and contribute to the template (and fix bugs like this). What do you think of moving it back into this repo? Would it go in the "downloads" folder?

[dorbin]

Yeah, I don't know why those templates were deleted from here, and whether/where they were moved to.

@anshrma and @edwinavalos , I don't know if either of you remember the PR Clare has linked (#926 ), but feel free to chime in.

Failing that, as far as I'm concerned if it fixes the problem to add them back where they were, and doesn't break whatever Anuj and Edwin were trying to do in that PR, please do put them back in. I don't have an opinion on whether they should go back where they were or in the downloads folder; you can probably assess better than I can which is the safer option.

@plumpy FYI

Also, @brian-armory and @aimeeu FYI, w/r/t the migration to the new repo.

[clareliguori]

The template bug is now fixed as #2020, so this change can be reverted @anooptejt

[clareliguori]

Does this also assume Spinnaker is deployed on EKS?

[anooptejt]

For, managing accounts we need access and secret keys. In the CLI by default instruction is provided to keep it true, whereas in the Manual no instructions are provided for the Authentication purpose. Again this was validated on Spinnaker being deployed all Kubernetes platforms

[clareliguori]

But this is not needed if Spinnaker is deployed directly to EC2 (not on Kubernetes). Option 2 below more clearly states the options for the UseAccessKeyForAuthentication option. So this should be something like:
If you want to use Access Keys and Secrets to run Spinnaker, set the UseAccessKeyForAuthentication parameter to True. If you want to use an EC2 instance profile to run Spinnaker, set the UseAccessKeyForAuthentication parameter to False.

[anooptejt]

For a localdebian spinnaker or distributed spinnaker if we need the halyard to access AWS to Bake, Create Instance or anything IAM roles and user access is mandatory. Which means Access and Secret are needed.

[clareliguori]

The SpinnakerManaged role is required, but EC2 instance profile can be used by Spinnaker to assume the SpinnakerManager role in the case of localdebian install on EC2. User access keys are not required in that case.

[clareliguori]

It would be better to have instructions on how to add a new managed account post-stack-creation by adding it to the template in the SpinnakerAssumeRolePolicy section and then updating the existing CloudFormation stack.

[aleon1220]

Hi All, sorry to be a party pooper. This PR is going to conflict with my PR #1996
I added all the manual steps to set up the AWS IAM structure. I called it Option-3
Any ideas on how to merge this safely.
This is actually a great contribution for the AWS Provider. Plus it opens the doors to add more details to the ECS, EKS and Lambda providers.

[clareliguori]

@aleon1220 which changes from this PR are you interested in getting merged specifically? Based on the review conversation, the only change in this PR I'm comfortable getting merged right now is the addition of the halyard bakery command, which seems minor enough that it shouldn't block your PR.

[aleon1220]

@aleon1220 which changes from this PR are you interested in getting merged specifically? Based on the review conversation, the only change in this PR I'm comfortable getting merged right now is the addition of the halyard bakery command, which seems minor enough that it shouldn't block your PR.

In that case it will be best for me to let you guys finish your merge and then from master i re-create my changes. I will save a local copy of my branch and removed the current PR so that you can merge.

[aleon1220]

Hello @clareliguori My PR #1996 has been merged.
Let me know @anooptejt if you want some discussion on my changes. All I did was to describe the manual set up of the AWS IAM structure.
Now that I am done my goal is to install K3S in at least 3 cloud providers again and test any deployment to AWS EC2.
Have a great weekend.