Keeping accounts decoupled is important in cross account scenarios. Setting permissions in the wrong way can lead to unwanted behavior. Better avoid setting a principal in a resource policy to a specific ARN as it may lead to ‘Invalid Principal’-errors. Using conditions provides you a more reliable and least privileged architecture.
AWS Setup: Secure Identity Foundation with Terraform When it comes to access management in AWS, often I see a basic setup, with Users in IAM, as described here. Clearly, most people focus on building actual running applications, at first. After the first running POCs, the next migrations are on the road map; your architecture evolves, but the initial IAM setup stays. So it’s better to have a super secure set-up right from the beginning.
According to the Well-Architected Framework and the least privileges principle, you should change your access keys and login password regularly. Therefore the user should have the right to edit their credentials. But only their own. Also using MFA - multi-factor authentication enhances the security even more. Therefore the user should be able to change MFA. But only their own. But how to do that? You have to combine two parts of AWS documentation. We will show you how you provide a “self-editing” group for your users with the CDK.
Do not use new Instance Metadata Service V2 (imdsv2) without proper prevention! You may think you can use Instance Metadata Service V2 right away, but there are a few caveats: Many old modules do not work with imdsv2 yet. We look at aws cli, the Systems Manager agent and the Instance Connect service. Currently, these services will not work with imdsv2 on an EC2 instance with the latest Amazon Linux 2 image out of the box. Here you can read how to make them work!
AWS S3 bietet viele Möglichkeiten, den Zugriff zu regeln S3 Buckets bieten flexible Möglichkeiten, Daten abzulegen und den Zugriff auf diese Daten zu beschränken. Dies für den öffentlichen (Internet) und internen Gebrauch. Über die normalen Berechtigungen (Permissions) lassen sich Berechtigungen ganz grob für “list” (Anzeigen), “upload/delete” (Schreiben), “view permissions” (Berechtigungen sehen) sowie “edit permission” (Berechtigungen schreiben) einstellen. Das reicht für viele Fälle, manchmal braucht man aber eine feinere Berechtigungsverwaltung, der bucket policy.
Das AWS Command Line Interface (CLI) erlaubt es Ihnen AWS Services einfach und bequem zu verwalten. Mit dem CLI können Sie im Terminal interaktiv Aufgaben bewältigen ohne die AWS Management Console benutzen zu müssen, was einen höheren Automatisierungsgrad ermöglicht. Außerdem können Shell-Skripte mit der Hilfe des AWS CLI verwendet werden um Infrastruktur-Setups zu automatisieren. Ein Beispiel: mit einem kleinen Shell-Skript und der AWS CLI kann zum Beispiel am Ende des Boot-Prozesses einer EC2-Instanz ein EBS Volume verbunden oder ein DNS-Eintrag über Route 53 angepasst werden.
