Configure Cross-Account Access with AWS Organizations

Поділитися
Вставка
  • Опубліковано 10 лют 2025
  • One of the features of using AWS Organizations is the ability to manage member accounts from either the management account or another identities account. You don't want to duplicate creating IAM users in each member account that you need access to.
    Using the AWS OrganizationAccountAccessRole (which you need to configure) will enable you to have users in the management account perform a role switch into any of the member accounts. You can then access services and resources in those member accounts depending on the permissions you have been granted.
    In this video, we show you have to configure cross-account access for your AWS Organization member accounts.
    AWS Certified Solutions Architect SAA-C03 - iaasacademy.com
    AWS How-To-Guides: iaasacademy.co...
    Book a mentoring call to discuss your cloud career options here: calendly.com/r...

КОМЕНТАРІ • 25

  • @kenny9239
    @kenny9239 9 місяців тому +2

    good work in explaining that 🙂

  • @EghosaOmo
    @EghosaOmo 2 роки тому +1

    Thank you, I look forward to more contents.

  • @gwulfwud
    @gwulfwud Рік тому +1

    that was a really good explanation of it.

  • @anjuyeddu5102
    @anjuyeddu5102 2 роки тому +2

    clear and precise! Thank you!

    • @awstraining
      @awstraining  Рік тому

      Glad it was helpful! We will be coming out more videos soon and if you need to learn anything specific, do let us know...

  • @Pablo-of8zm
    @Pablo-of8zm Рік тому +1

    God bless you

  • @umairaziz5363
    @umairaziz5363 10 місяців тому +1

    i ahve one question, that can we only invite or add root accounts to AWS organization or we can IAM accounts too ?

    • @awstraining
      @awstraining  10 місяців тому

      Yes, you can configure IAM accounts which need to be able to assume the Cross Account Access Role (OrganizationAccountAccessRole) and then they can perform the cross account access.

  • @orangekitty5192
    @orangekitty5192 2 роки тому +1

    super helpful!

    • @awstraining
      @awstraining  2 роки тому

      Thank you very much... more AWS videos to follow

  • @flamecrow
    @flamecrow Рік тому +1

    I’m new to AWS and this seems so confusing to me. What happens if the Development account that was invited (disgruntled employee) quits his job and leaves the Organization (company)?
    Does all the dev EC2 instances he has created leave with him too?
    Can Alice still switch roles into the Development account role to make changes to the dev EC2 instances?
    Can the Development account (disgruntled employee) remove the cross account Organization Role with Full Access Policy to stop Alive from switching role into the Development account?
    And finally, if the dev EC2 instances are still in Development account, can this disgruntled employee sabotage the company by delete all the dev EC2 instances?

    • @awstraining
      @awstraining  Рік тому

      Hi,
      Thank you for your questions and these are very good questions to ask too.
      So remember that it is the AWS account that was invited, not the IAM User that belongs to the (disgruntled employee). The account is still a separate entity from the actual IAM user. To ensure that the disgruntled employee doesn't try to remove the development account from the AWS Organization, we applied an SCP to prevent administrators from doing so. Furthermore, you probably would not want the employee having such permissions (assigned through IAM Policies) anyway.
      Therefore Alice will still be able to switch roles and manage the development account regardless of the employee leaving the organization. And Alice will be able to manage the EC2 instances that the disgruntled employee was taking care of.
      Your third question is very interesting. One of the biggest issues with assigning polices to IAM users (such as the disgruntled employee) is how to ensure they do not take advantage of their privileges. That's where the concept of AWS IAM Permission Boundaries come into play. IAM Permission Boundaries allows you to enforce guardrails that prevent IAM Users from exploiting the IAM Policies that are attached to their accounts or groups they belong to. You can create a permission boundary that prevents the employee from deleting or removing any IAM roles that have been assigned. Check out out video on IAM Permission Boundaries at ua-cam.com/video/LZdfxS2DnFw/v-deo.html
      For more details you can also look at this page: aws.amazon.com/blogs/security/when-and-where-to-use-iam-permissions-boundaries/
      Lastly, you can actually prevent IAM users from being able to call the ec2:TerminateInstances API action. Obviously there is always the risk factor of a user who may have elevated privileges and so you need to ensure that you also have adequate business processes in place in additional the technical guardrails you define for your cloud platform.
      Hope this helps
      Kind regards
      Rajesh

    • @flamecrow
      @flamecrow Рік тому +1

      @@awstraining Thank you Rajesh! I finally understand now, the terminology kept me confused as I kept interchanging "users" and "AWS accounts" as the same thing.

  • @hembromjohn
    @hembromjohn 3 місяці тому +1

    Is role switch features, disappears after logout. Yesterday, I set the roles orgaccessrole for the member account. Today after logging in from mgmt IAM , the roles his gone.. my question is do we need to set switch role each day? Kindly guide

    • @awstraining
      @awstraining  3 місяці тому +1

      Hi
      Thank you for your message. Yes, after you switch back to the management account, you must perform the switch role operation again to access the other accounts. In AWS, switch roles are a temporary action and make use of temporary security credentials granted by the IAM role.
      You may find that when you click on the Account Name on the top right hand corner of the management console webpage of the management account, a link would exist with previously role switch operations. You can use this to perform the role switch operation again. This is just a link - ultimately you are performing a role switch operation every time you wish to move from one account to the other.
      Hope this helps.
      Kind regards
      Rajesh

    • @hembromjohn
      @hembromjohn 3 місяці тому +1

      @@awstraining Thanks so much for the detailed guidance and giving your time for replying! Would you like to answer one more question- Each time I want to purchase from route53, it says
      " We can't finish registering your domain. Contact AWS Support at" Why this happens & can we ourselves fix this?

    • @awstraining
      @awstraining  3 місяці тому +1

      Hi,
      The Route53 error message usually occurs when your contact details are not complete. Check you account profile and contact details to ensure its complete, because this information is required for WHOIS records.
      Another possible reason could be related to credit/debit card details. Check you have a valid credit/debit card associated with your account.
      Hope this helps
      Thanks
      Rajesh

    • @hembromjohn
      @hembromjohn 3 місяці тому +1

      @@awstraining Thank you I'll update contact details. Actually there are some AWS credit in my mgmt account And I wanted to use it in my Org member account to purchase domain for it with OrgAcctAccsRole. Maybe in billing sections of member account I need update, but thanks so much outlining the possible causes.

    • @awstraining
      @awstraining  3 місяці тому +1

      No worries, happy to help!

  • @BK-rf8ck
    @BK-rf8ck 2 роки тому +1

    Thanks for your hard work.. and I have a question to ask to clarify the whole process. I mean, isn't there any need to make a policy of STS for any IAM user(Alice for example) in management account to actually assume the role given by the member account?

    • @awstraining
      @awstraining  2 роки тому +1

      Thanks for your query BK. So yes, in the above example, Alice has full administrative permissions so that was fine. For standard IAM users you will want to create a policy that uses the STS Assume Role policy to be able to assume the role to access the member account. An example policy would be like this (where you would need to provide the account ID that hosted the role):
      {
      "Version": "2012-10-17",
      "Statement": [
      {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::xxyyzzxxyy:role/OrganizationAccountAccessRole"
      }
      ]
      }
      You would then attach the role to the user directly to better still to a group that the user was a member of for easier management.
      Hope this help :)

    • @BK-rf8ck
      @BK-rf8ck 2 роки тому

      @@awstraining thank you for your kind response... i really enjoy your aws related classes in udemy... you're the best teacher i've ever taken lessons from.