Having used this for a while, a few caveats.. You need to use AWS CLI v2, its been out for a while now though so there is not much reason not to upgrade. This is to support the AWS SSO elements of logging in and managing credentials AWS SAM does not yet support SSO, so the SAM cli will still require you to setup a profile with traditional keys. The SSO start page will provide you with temporary credentials, or you will need to create a dedicated IAM role in the account you want to use SAM with.
Great video. What is the point of the VPC of the Accounts Factory? My understanding is that each account created/enrolled with the Account Factory will have that VPC as the default account VPC. But is that it ? I don't understand what's the benefit of this.
I like the hair and the use of Morty was brilliant. Just on the use of a root account a bit more. This is a mistake that many sysadmins make. When a hacker takes advantage of an overflow of something worse, this can enable full (RCE) under root access if you have not set the privileges accordingly. You will have heard the term (privilege escalation); well you don’t need to “escalate” the privileges if said process or system was deployed and granted root priv. Root is the same as Administrator under windows. Setting the correct permissions when using AWS, Azure or Google is step one in good security. Well done on the video.
thanks for the praise @Nicholas. It is never a great idea to run as root, in the AWS account context it is different to a PC context, it relates to action permissions on the platform such as creating instances and modifying resources. In this instance I was using it to enable billing for none root users and creating users that can have more fine grained permissions control. Spot about setting the correct permissions and following root privilege, it also pays to be mindful of parallels with system RCE on the platform, ensuring tools and servers do not have roles that would allow broad ranging actions on the platform that can be exploited
@@MOAMindustries "in the AWS account context it is different to a PC context" no i got that part but AWS inherits the fundamentals of RHEL and Cent. you could say their entire "cloud" is still KVM though it's far from now. if you use the same concept with a Linux system and apply it to how they manage permissions, that's the ticket!. same as google and azure. they all have the same idiosyncrasies that Linux has. i digress. the importance of privileges is to contain each executable. this also applies to the AWS web UI. you will find a Linux platform behind all AWS services, whether its the Web UI or not.
so containing privileges is not just a security practice but good for programming. overflows and corruption, whilst used as in many exploits, it is also a by-product of bad code, which i and many others are guilty of. so if the overflow happens, malicious or not, it won't corrupt other processes running. I was enforcing what you said about permissions and how important they are in system you have. understanding the privileges of Linux will apply to how you use the WEB UI on AWS, Google and Azure.
Control Tower is an orchestration/wizard process that utilises landing zones and organisations. AWS Organisations is the low-level element of aggregating sub accounts into a master account Landing zone provides the tools for installing guardrails, security, reporting around managing sub accounts. As I understand it, Landing Zone is very complex and can be difficult to setup, really aimed at enterprise customers or those who support them. Control tower essentially makes a landing zone that is 'good enough' for 99% of use cases.
Having used this for a while, a few caveats..
You need to use AWS CLI v2, its been out for a while now though so there is not much reason not to upgrade. This is to support the AWS SSO elements of logging in and managing credentials
AWS SAM does not yet support SSO, so the SAM cli will still require you to setup a profile with traditional keys. The SSO start page will provide you with temporary credentials, or you will need to create a dedicated IAM role in the account you want to use SAM with.
Love, love, love this explanation! Thank you!
This was so simple. We had a session with AWS presenter. We couldn't understand anything he said. Thank you.
A lot more informative than any of the official AWS buzzword filled presentations I've found. Thanks
Thank you!
Great video.
What is the point of the VPC of the Accounts Factory? My understanding is that each account created/enrolled with the Account Factory will have that VPC as the default account VPC. But is that it ? I don't understand what's the benefit of this.
"you have to excuse the dog is snoring away in the corner, he's not at all fussed about this"
Great explanation. This helped alot!
Good stuff! Found it very informative
Nice video
I like the hair and the use of Morty was brilliant. Just on the use of a root account a bit more. This is a mistake that many sysadmins make. When a hacker takes advantage of an overflow of something worse, this can enable full (RCE) under root access if you have not set the privileges accordingly. You will have heard the term (privilege escalation); well you don’t need to “escalate” the privileges if said process or system was deployed and granted root priv. Root is the same as Administrator under windows. Setting the correct permissions when using AWS, Azure or Google is step one in good security.
Well done on the video.
thanks for the praise @Nicholas. It is never a great idea to run as root, in the AWS account context it is different to a PC context, it relates to action permissions on the platform such as creating instances and modifying resources. In this instance I was using it to enable billing for none root users and creating users that can have more fine grained permissions control. Spot about setting the correct permissions and following root privilege, it also pays to be mindful of parallels with system RCE on the platform, ensuring tools and servers do not have roles that would allow broad ranging actions on the platform that can be exploited
@@MOAMindustries "in the AWS account context it is different to a PC context" no i got that part but AWS inherits the fundamentals of RHEL and Cent. you could say their entire "cloud" is still KVM though it's far from now. if you use the same concept with a Linux system and apply it to how they manage permissions, that's the ticket!. same as google and azure. they all have the same idiosyncrasies that Linux has. i digress. the importance of privileges is to contain each executable. this also applies to the AWS web UI. you will find a Linux platform behind all AWS services, whether its the Web UI or not.
That was an awesome video :)
so containing privileges is not just a security practice but good for programming. overflows and corruption, whilst used as in many exploits, it is also a by-product of bad code, which i and many others are guilty of. so if the overflow happens, malicious or not, it won't corrupt other processes running. I was enforcing what you said about permissions and how important they are in system you have. understanding the privileges of Linux will apply to how you use the WEB UI on AWS, Google and Azure.
Thank you Brow!
Thanks for this. I am looking to understand the difference between Control Tower, Landing Zones and Organizations. Anybody care to comment?
Control Tower is an orchestration/wizard process that utilises landing zones and organisations.
AWS Organisations is the low-level element of aggregating sub accounts into a master account
Landing zone provides the tools for installing guardrails, security, reporting around managing sub accounts. As I understand it, Landing Zone is very complex and can be difficult to setup, really aimed at enterprise customers or those who support them.
Control tower essentially makes a landing zone that is 'good enough' for 99% of use cases.