#geodesic (2021-02)

@Mathieu SERRA we have some incoming documentation on this from @Matt Gowie

https://github.com/cloudposse/terraform-aws-components/pull/297

Should be merged today

Ok thanks for your help. It’s help a lot. One question regarding variables assume_role_restricted in iam-primary-roles. I need to set to false first when I created all the roles for a cold start. But does I need to relaunch terraform process after creation with this variable to true in the identity account ?

@Jeremy G (Cloud Posse) @Dan Meyers

Sorry it is so complex, @Mathieu SERRA, but you seem to be getting the hang of it. We recommend creating an identity account separate from the root account and creating the primary roles in that account.

When assume_role_restricted is true, we add limitations on roles to prevent them from assuming other roles in the same account. For example, identity-observer is not allowed to assume identity-ops. However, we cannot create that restriction until after both identity-observer and identity-ops have been created, so when first creating the roles you have to set assume-roles-restricted to false so we do not create rules referencing non-existent roles. Then you need to do terraform apply in order to actually create the roles. After the roles are created, you can set assume-role-restricted back to true and terraform apply to create the restrictions.

@Jeremy G (Cloud Posse) Thanks for yor complete answer. I’ve followed your instruction but I’m facing an issue. I’ve taken your example and put this in var for the module iam-primary-roles :

delegated_roles_config:
          admin:
            role_policy_arns: [ "arn:aws:iam::aws:policy/AdministratorAccess" ]
            role_description: "Role with AdministratorAccess permissions"
            sso_login_enabled: false
            # list of roles in primary that can assume into this role in delegated accounts
            # primary admin can assume delegated admin
            trusted_primary_roles: [ "admin" ]

I take this configuration from you readme. But I juste disable the sso for the moment I will only use aws user. For the first appliance with assume_role_restricted to false no error the role is correctly created. But when I set assume_role_restricted to true and relaunch terraform apply the assume role policy of the admin role is replace with null:

assume_role_policy    = jsonencode(
          ~ {
              ~ Statement = [
                  - {
                      - Action    = [
                          - "sts:TagSession",
                          - "sts:AssumeRole",
                        ]
                      - Effect    = "Allow"
                      - Principal = {
                          - AWS = "arn:aws:iam::x:root"
                        }
                      - Sid       = "IdentityAccountAssume"
                    },
                ] -> null
                Version   = "2012-10-17"
            }
        )

If we look your code it’s seems that you exclude in trusted_primary_roles all the role who has the same name that the role to create or update.

Yes, no identity role is allowed to assume the identity-admin role. Also, because of the limitations of role chaining, we do not allow any role to assume itself. We would rather have an error if that situation arises so we can fix whatever is causing that to happen.

Thanks for your answer. You said that you not allow any role to assume itself but in readme of iam-primary-roles you put the admin as himself trusted primary role:

delegated_roles_config:
          admin:
            role_policy_arns: [ "arn:aws:iam::aws:policy/AdministratorAccess" ]
            role_description: "Role with AdministratorAccess permissions"
            sso_login_enabled: false
            # list of roles in primary that can assume into this role in delegated accounts
            # primary admin can assume delegated admin
            trusted_primary_roles: [ "admin" ]

And how I can correctly configure the admin role with no trusted_primary_roles and sso disable without having a null assume_role_policy when I set assume_role_restricted to true ? Thanks

admin is trusted in delegated roles. This is a shorthand for saying identity-admin can assume otherAcct-admin. When you set assume_role_restricted = true then the roles are automatically restricted from assuming themselves as well.

This is the point of having target_role here

if ! contains([target_role, "cicd"], source_role) 

Thanks for your answer. I have know a better view of how it’s work. Do you know I can fix my issue when I put assumed-role-restricted to true. When I set to true the assume role policy of the root role become null. So terraform raise an error:

assume_role_policy    = jsonencode(
          ~ {
              ~ Statement = [
                  - {
                      - Action    = [
                          - "sts:TagSession",
                          - "sts:AssumeRole",
                        ]
                      - Effect    = "Allow"
                      - Principal = {
                          - AWS = "arn:aws:iam::x:root"
                        }
                      - Sid       = "IdentityAccountAssume"
                    },
                ] -> null
                Version   = "2012-10-17"
            }
        )

I have the following config for the delegated-role-config

delegated_roles_config:
          admin:
            role_policy_arns:
              - "arn:aws:iam::aws:policy/AdministratorAccess"
            role_description: "Admin role"
            sso_login_enabled: false
            trusted_primary_roles: [admin]
          terraform:
            role_policy_arns:
              - "arn:aws:iam::aws:policy/job-function/ViewOnlyAccess"
              - "delegated_assume_role"
            role_description: "Role with permissions for terraform automation"
            sso_login_enabled: false
            trusted_primary_roles: ["admin", "terraform"]

Thanks

You need to give me more context. I can’t find jsonencode anywhere. Are you using the latest versions of everything?

Oh, so when you run it with no arguments it outputs a bash script installer

(On my phone

The result is a script is installed that helps you start it since running long Docker commands is no fun

If you just want to kick the tires and skip installation, then add -l

ah ok now it works. ya i just wanted to try it out

The way we use it is as a base Docker image for our customers

We also have Debian and CentOS images

We like to mount $HOME to /localhost so we can access files during development (e.g. tf)

you dont mount it to /conf the root $HOME ?

No…

oh i see i see. got it working

Conf is where we copy the configurations for distribution in the Docker file that is FROM geodesic

https://github.com/cloudposse/packages/tree/master/vendor

All of these tools are easily installed. We update every night automatically

hmmm

⨠ aws-vault exec sso_sre --server
Enter passphrase to unlock /conf/.awsvault/keys/:
Enter passphrase to unlock /conf/.awsvault/keys/:
Enter passphrase to unlock /conf/.awsvault/keys/:
aws-vault: error: exec: fork/exec : no such file or directory

thanks for the help. i’ll keep playing with it

I think we do some symlinking for that

Check out /etc/profile.d

ya i was trying to use the same profiles i have setup locally

That should work

i can see my profiles when doing aws-vault list

Aha are you on a Mac?

lol. yessir

So I think you need to use the vault backend of file for it to work across OS barriers

Docker cannot access keychain

Used

docker run --env AWS_VAULT_BACKEND=file -v "$HOME:/localhost" -it cloudposse/geodesic -l

then

⨠ env | grep AWS_VAULT
AWS_VAULT_SERVER_ENABLED=false
AWS_VAULT_BACKEND=file
AWS_VAULT_ENABLED=false
 ⧉  geodesic
 √ . [default] ~ ⨠ aws-vault exec sso_sre --server
Enter passphrase to unlock /conf/.awsvault/keys/:
aws-vault: error: exec: fork/exec : no such file or directory

this seems to work tho

aws-vault exec sso_sre -- aws sts get-caller-identity
Enter passphrase to unlock /conf/.awsvault/keys/:

{
    "UserId": "snip",
    "Account": "snip",
    "Arn": "snip"
}

@Jeremy G (Cloud Posse) may know

are we talking about atmos ?

…are you using helmfile with helm?

…what’s calling helm?

woops, yeah atmos. i think i read something about helmfile supporting tfstate

er tfstate-lookup

exactly - so you shouldn’t have state based between anything in atmos, you should use the tools ability to access remote state.

helmfile can read from SSM or terraform remote state

loving this so far

https://github.com/cloudposse/helmfiles/blob/a9e11bfe51fc5b60090f8c85d2c63c7716084bad/releases/codefresh-runners/helmfile.yaml#L35

here’s how to read from SSM in helmfile

if you’re using pure helm, then what you’d want is that terraform uses the kubernetes provider to write a ConfigMap or Secret instead

got it. going to jump on this tonight when i get back. thanks for help!

also, once you have this stuff working in atmos, you should be able to use spacelift very easily too.

https://registry.terraform.io/modules/cloudposse/cloud-infrastructure-automation/spacelift/latest

hrmmm @Jeremy G (Cloud Posse) mentioned something about the problem being introduced. have you seen this workaround?

Docker really blew it with the 3.x version and people are pretty steamed. If there were an alternative to Docker, people would be flocking to it, which I am sure has some people working to set up an alternative to it.

Yes, I knew about turning off gRPC Fuse. Sadly, the alternative, OSX Fuse, as used by Docker, seems to have a memory leak. I had it using > 70 GB of swap. But the CPU is manageable and memory leaked to swap is not a big deal since by virtue of it being leaked, it is never paged back in.

podman is the best alternative I can see https://podman.io/. That could be combined with https://github.com/gyf304/vmcli or https://github.com/machyve/xhyve or https://github.com/moby/hyperkit to make a suitable docker alternative for OSX. You could also use https://developers.redhat.com/blog/2020/02/12/podman-for-macos-sort-of/

@Matt Gowie this is one of the things I ran into and had a question about as well. I did the same thing as Mathieu. Is the longer term intent to do something like terraform-null-label but for the tfstate-context?

Ah yeah the [tfstate-context.tf](http://tfstate-context.tf) files was a pattern that I believe the CP team tried out, but it didn’t work out and was deprecated.

I see, thanks. Do you know if there is something more up to date that I should look at?

@Mathieu SERRA @Joe Hosteny The issue with the above usage of iam_roles is that the account-map version likely doesn’t have the latest iam_roles submodule which causes issues. We need to get everything up-to-date and get it all working together which unfortunately we’re waiting on PR reviews and some time from some of the more in-the-know Cloud Posse team members.

Thanks @Matt Gowie. Not sure if you caught my message above while you were typing out your last one. Or maybe you meant that was part of the pending work?

I believe it’s like just a disconnect between the pending work and what has merged. Let me check again what has merged so I know which direction it is borked in.

Yeah so I believe the issue is likely that these components haven’t landed yet: https://github.com/cloudposse/terraform-aws-components/pull/304

Once those are merged in, we’ll have the most up-to-date iam_roles submodule and then things start to fit together better.

Thanks! I may try to merge those into my local repo

Honestly… I believe we’re going to need to pull that submodule out and start versioning submodule usage instead of relying on path based modules because these types of issues crop up.

cc @Erik Osterman (Cloud Posse) for discussion / context later.

Also we need a #sweetops channel Talking about this in #geodesic aint right.

(It’s the best we’ve got, but we need a better spot to talk about atmos, stacks, components, and all the things)

Yeah, sorry - I think I saw some other discussions regarding the new structure here.

Ah nothing to be sorry about — Really thinking out loud more than anything.

BTW, I was working from the all-new-components branch. I diff’ed a lot of the changes between that and the upstream-account-comps branch, and wound up just deleting the tfstate-context.tf and tfstate.tf files from the account-map component, and everything worked cleanly

With applying twice (first time w/ assume_role_restricted: false)