TIB Academy Offers best AWS training in bangalore. this tutorial contains the following aspects,
security mind map
identity and access management
IAM policies
Incoming and Outgoing Shipments in 1 STEP Using Odoo 17
best aws training in bangalore
1.
2. VPC (Virtual Private Cloud)
Build a most commonly used network architecture with a
CloudFormation Template
Entire Data Centre Networking Infrastructure in <20min
3. AWS Organizations
Architecting Governance and Security with multi-account strategy
Immutable Architecture
Security Control Policies: BL / WL
6. Enables us to control who can do what in our AWS account
Secure (deny) by default
Global service
7. https://alias.signin.aws.amazon.com/console
( redirected to a regional sign-in endpoint such as https://us-east-
2.signin.aws.amazon.com, resulting in a regional CloudTrail log entry
in the user's region's log )
https://alias.signin.aws.amazon.com/console/s3
( AWS redirects you to the global sign-in endpoint at
https://signin.aws.amazon.com, resulting in a global CloudTrail log
entry )
https://alias.signin.aws.amazon.com/console/ec2?region=ca-
central-1
(results in a CloudTrail log event in that region)
8.
9.
10. Create individual users
Grant least privilege
Manage permissions with groups
Restrict privileged access further with conditions
Enable AWS CloudTrail to get logs of API calls
Configure a strong password policy
Rotate security credentials regularly.
Enable MFA for privileged users
Use IAM roles to share access
Use IAM roles for Amazon EC2 instances
Reduce or remove use of root
https://www.slideshare.net/AmazonWebServices/sec302-iam-best-practices-to-live-by
11. A policy is a document that contains one or more permissions.
Each permission describes actions that are allowed or not allowed
Written in JSON
User Based or Resource Based
Managed Policies and Inline Policies
Managed Policies:
AWS managed policies
Customer managed policies
Managed Policies feature:
Reusability
Central change management
Versioning and rolling back
Delegating permissions management
Automatic updates for AWS managed policies
Inline Policies feature:
Embedded into user/group/role
Strict one to one relationship between a policy and the principal entity that
it’s attached
What happens to a inline policy when we delete a principal entity that it’s
attached to?
12. Requests that are made by the AWS account root user are allowed for resources in that account.
IAM user in an account that is in an organization can use the intersection of the permissions allowed by
both Organizations SCPs and by the IAM permission policies
13. Attached to a User, Group, or Role
Policies DO NOT specify a Principal (User/Group/Role); it is implied
14. Attached to a resource such as S3 Bucket or DynamoDB Table
Policies DO specify a Principal (User/Group/Role)
Policy describes what access is assigned to the principal
15. Allows us to treat resources as a unit (i.e. project
Allows us to autmatically enforce permissions when new resources are
created
Supported services: EC2,VPC, EBS, RDS, SWS, Data Pipeline
16. Amazon Resource Names (ARNs) uniquely identify AWS resources. We require an ARN when you need to specify a resource unambiguously across all of AWS,
such as in IAM policies, Amazon Relational Database Service (Amazon RDS) tags, and API calls.
The following is the common Amazon Resource Name (ARN) format to identify any resources in AWS.
arn:partition:service:region:namespace:relative-id
General formats for ARNs; the specific components and values used depend on the AWS service.
arn:partition:service:region:account-id:resource
arn:partition:service:region:account-id:resourcetype/resource
arn:partition:service:region:account-id:resourcetype:resource
<!-- Elastic Beanstalk application version -->
arn:aws:elasticbeanstalk:us-east-1:123456789012:environment/My App/MyEnvironment
<!-- IAM user name —>
arn:aws:iam::123456789012:user/David
<!-- Amazon RDS instance used for tagging -->
arn:aws:rds:eu-west-1:123456789012:db:mysql-db
<!-- Object in an Amazon S3 bucket -->
arn:aws:s3:::my_corporate_bucket/exampleobject.png
Paths in ARNs
arn:aws:iam::123456789012:user/Development/product_1234/*
"Resource":"arn:aws:iam::123456789012:user/*"
"Resource":"arn:aws:iam::123456789012:group/*"
http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-rds
18. AWS assigns two unique IDs to each AWS account:
An AWS account ID (123456789012)
A canonical user ID - an obfuscated form of the AWS account ID
(79a59df900b949665d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2b
e)
19. You cannot use a wildcard to specify all users in the Principal element in
a resource-based policy or a role trust policy.
You cannot use groups as principals in any policy.
You can use wildcard characters (* and ?) within any ARN segment
You can specify user/* to mean all users or group/* to mean all groups
20. Effect - Required - specifies statements result is “Allow” or “Deny
Principal - Required for Resource Policies only
Action - Required - An AWS Service “Action” that statement applies to
Resource - Required - An AWS object (ARN) that statement applies to.
Condition - Optional
21. Version policy element defines the version of the policy language
Statement policy element is the main element for a policy
Sid (Statement ID)
Notprincipal (Effect: Allow with Notprincipal allows access to
anonymous (unauthenticated) uses; try not to use Notprincipal)
Notaction
30. Write a policy granting minimal set of permissions
Let default ‘Deny’ prevent access to everything else
Create a test user
Attach the policy to the test user
Make API / CLI calls as the test user with Dry Run option
Confirm that policy works as intended
If errors out, use AWS STS Encoded Authorization Message API to
decode the error
Tweak the policy
Iterate
31. An AWS identity with permission policies that determine what the
identity can and cannot do in AWS.
Temporary privilege escalation
Enable users to perform a task that they normally would not be able
to do (kind of like ‘sudo’ command)
A user can only assume one Role at a time
Roles can be passed to EC2 Instances
Credentials passed through a role have pre-set expiration times
32. Reduced the surface area of attack
Temporary authentication credentials
Auditable activity
Automatically generated authentication credentials
Limited privilege
33. Any process or user running on the EC2 instance with access to the
instance metadata can access the credentials
Instances with Role need to implement their own access control
measures if users will be logging into the instances
Ask yourself: Do users need to log into the instances?
34. After you create a role and grant your user permissions to switch to it,
you must provide the user with the role name and the account ID
number or account alias that contains the role. You can make things
easier for your users by sending them a link that is preconfigured with
the account ID and role name.
You can see the role link on the final page of the Create Role wizard
or in the Role Summary page for any cross-account enabled role.
https://signin.aws.amazon.com/switchrole?account=YourAccountIDor
AliasHere&roleName=pathIfAny/YourRoleNameHere
We’ll talk at AP level which equally applies to the actions in the console, CLI, or SDK. We’ll look at permissions needed for programmatic access and permissions required for the AWS console access.
Frequent anti-pattern is to create a user and then bake user’s credentials in application so that application can access them (for example, in a file, Windows registry etc). Credentials are stored in source repos and never rotated. Is there an easy way to avoid the madness of hard-coded credentials??
AWS Organizations service creates InfoSec Account and “OrganizationAccountAccessRole-InfoSec” role in the new SecInfo account.
Admin in Master Account grants a group permission to call “OrganizationAccountAccessRole-SecInfo” role
A user in Master Account requests access to the role
STS returns roles credentials
User switches role and becomes administrator in SecInfo Account
When you create a role for cross-account access, you establish trust from the account that owns the role and the resources (trusting account) to the account that contains the users (trusted account). To do this, you specify the trusted account number as the Principal in the role's trust policy. That allows potentially any user in the trusted account to assume the role. To complete the configuration, the administrator of the trusted account must give specific groups or users in that account permission to switch to the role.
IAM evaluates policies at run time
Also can use account ID instead of alias
Create a new account.
Record account # and role name.
Create an OU
Move newly created account into the new OU.
Create a new SCP and attach it to a new OU
Create a group.
Assign cloud_admin user to the group.
Create an inline policy that allows the user to assume the role
Demonstrate switching roles
Inline - embedded into user/group /role; deleted with user/group/role; strict one to one relationship between a policy and the principal entity that it's attached
Requests that are made by the AWS account root user are allowed for resources in that account.
IAM user in an account that is in an organization can use the intersection of the permissions allowed by both Organizations SCPs and by the IAM permission policies
Partition: aws (or aws-cn in China)
Service: s3
Don't specify region and namespace for S3 global service
Bucket-name or a bucket-name/object-key or wild card
ou can also use the Amazon S3 ListBuckets API to return the canonical user ID. For more information, see GET Service Response Elements in the Amazon Simple Storage Service API Reference.
We recommend that you set the Version element to 2012-10-17 for all policies.
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/myRole-S3-EC2
curl http://169.254.169.254/latest/meta-data/ <-must have slash
Run - launch
Start - starts stopped instance
Programmatically access home folder
http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html
Programmatically and in the Console
a role does not have any credentials (password or access keys) associated with it. Instead, if a user is assigned to a role, access keys are created dynamically and provided to the user.
Note that you can switch roles only when you sign in as an IAM user. You cannot switch roles when you sign in as the AWS account root user.
• When you switch roles in the AWS Management Console, the console always uses your original credentials to authorize the switch. This applies whether you sign in as an IAM user, as a SAML-federated role, or as a web-identity federated role. For example, if you switch to RoleA, it uses your original user or federated role credentials to determine if you are allowed to assume RoleA. If you then try to switch to RoleB while you are using RoleA, it still uses your original user or federated role credentials to authorize your attempt to switch to RoleB, not the credentials for RoleA.