08 - AWS Cloud Security and Access Management
08 - AWS Cloud Security and Access Management
Access Management
by TWN
No part of this publication may be reproduced, copied, transmitted in any
form or by any means, electronic, mechanical, photocopying, recording or
otherwise, without the prior written permission of nnSoftware GmbH
Our mission is enable individual engineers as well as companies to take advantage of the
recent developments in Cloud and DevOps fields, to use technologies and concepts in
order to create efficient, automated, streamlined DevSecOps processes in organisations.
1. We need to not only secure the 2. But also the access to the services
network and servers itself on the cloud platform
Administration
Usage
You do that by creating and configuring IAM users, groups, roles and policies:
Policy is a set of permissions that define what actions someone (who the policy
is attached to) is able to perform on which resources
You can give permissions on a very granular basis
Ability to limit further with conditions
Policies are stored in AWS as JSON documents
Security Best Practice is to only give enough permissions needed by the service to perform its
tasks. Not more.
GitLab needs relevant access to be able to:
interact with AWS ECR repository
deploy to EC2 instance
BUT nothing more!
For that, we want to create own dedicated user that has these restricted permissions
Now instead of using Root access keys, we can replace it with the restricted
GitLab access keys
Offers a secure way to grant permissions to entities, without the need for long-
term access keys
Roles are often used for services or instances that need to access other
services within the cloud environment
Similar to an IAM user, in that it is an Entities assume roles when they need
AWS identity with permission policies to perform certain actions on resources
Trust Policy
Roles have trust policy that defines which entities
are allowed to assume the role