AWS SAP Notes 01 - Permissions, Identity and Federation

Multi-Factor Authentication (MFA)

  • Factor: different piece of evidence which proves the identity
  • Factors:
    • Knowledge: something we as users know: username, password
    • Possession: something we as users have: bank card, MFA device/app
    • Inherent: something we are, example: fingerprint, face, voice, iris
    • Location: a location (physical) or which network we are connected to (corporate wifi)
  • More factors means more security, harder to bypass by an intruder

    IAM: Identity and Access Management

  • When accessing AWS, the root account should never be used. Users must be created with the proper permissions. IAM is central to AWS

  • Users: A physical person

  • Groups: Functions (admin, devops) Teams (engineering, design) which contain a group of users

  • Roles: Internal usage within AWS resources

    • Cross Account Roles: roles used to assumed by another AWS account in order to have access to some resources in our account
  • Policies (JSON documents): Defines what each of the above can and cannot do. Note: IAM has predefined managed policies

    • There are 3 types of policies:
      • AWS Managed
      • Customer Managed
      • Inline Policies
  • Resource Based Policies: policies attached to AWS services such as S3, SQS

Policies

  • IAM policies define permissions for an action regardless of the method that you use to perform the operation.

Policy types

  • Identity-based policies: attach managed and inline policies to IAM identities (users, groups to which users belong, or roles). Identity-based policies grant permissions to an identity
  • Resource-based policies: attach inline policies to resources. The most common examples of resource-based policies are Amazon S3 bucket policies and IAM role trust policies. Resource-based policies grant permissions to a principal entity that is specified in the policy. Principals can be in the same account as the resource or in other accounts
  • Permissions boundaries: use a managed policy as the permissions boundary for an IAM entity (user or role). That policy defines the maximum permissions that the identity-based policies can grant to an entity, but does not grant permissions. Permissions boundaries do not define the maximum permissions that a resource-based policy can grant to an entity alt text
  • Organizations SCPs: use an AWS Organizations service control policy (SCP) to define the maximum permissions for account members of an organization or organizational unit (OU). SCPs limit permissions that identity-based policies or resource-based policies grant to entities (users or roles) within the account, but do not grant permissions
  • Access control lists (ACLs): use ACLs to control which principals in other accounts can access the resource to which the ACL is attached. ACLs are similar to resource-based policies, although they are the only policy type that does not use the JSON policy document structure. ACLs are cross-account permissions policies that grant permissions to the specified principal entity. ACLs cannot grant permissions to entities within the same account
  • Session policies: pass advanced session policies when you use the AWS CLI or AWS API to assume a role or a federated user. Session policies limit the permissions that the role or user's identity-based policies grant to the session. Session policies limit permissions for a created session, but do not grant permissions. For more information, see Session Policies

Policies Deep Dive

  • Anatomy of a policy: JSON document with Effect, Action, Resource, Conditions and Policy Variables
  • An explicit DENY has precedence (quyền ưu tiên) over ALLOW
  • Best practice: use least privilege for maximum security
    • Access Advisor: a tool for seeing permissions granted and when last accessed
    • Access Analyzer: used of analyze resources shared with external entities
  • Common Managed Policies:
    • AdministratorAccess
    • PowerUserAccess: does not allow anything regarding to IAM, organizations and account (with some exceptions), otherwise similar to admin access
  • IAM policy condition:

    "Condition": {
        "{condition-operator}": {
            "{condition-key}": "{condition-value}"
        }
    }
    
  • Operators:

    • String: StringEquals, StringNotEquals, StringLike, etc.
    • Numeric: NumericEquals, NumericNotEquals, NumericLessThan, etc.
    • Date: DateEquals, DateNotEquals, DateLessThan, etc.
    • Boolean
    • IpAddress/NotIpAddress:
      • "Condition": {"IpAddress": {"aws:SourceIp": "192.168.0.1/16"}}
    • ArnEquals/ArnLike
    • Null
      • "Condition": {"Null": {"aws:TokenIssueTime": "192.168.0.1/16"}}
  • Policy Variables and Tags:

    • ${aws:username}: example "Resource:["arn:aws:s3:::mybucket/${aws:username}/*"]
    • AWS Specific:
      • aws:CurrentTime
      • aws:TokenIssueTime
      • aws:PrincipalType: indicates if the principal is an account, user, federated or assumed role
      • aws:SecureTransport
      • aws:SourceIp
      • aws:UserId
    • Service Specific:
      • ec2:SourceInstanceARN
      • s3:prefix
      • s3:max-keys
      • sns:EndPoint
      • sns:Protocol
    • Tag Based:
      • iam:ResourceTag/key-name
      • iam:PrincipalTag/key-name

Policy Evaluation Logic

  • Components involved in a policy evaluations:
    • Organization SCPs
    • Resource Policies
    • IAM Identity Boundaries
    • Session Policies
    • Identity Policies
  • Policy evaluation logic - same account: alt text
  • Policy evaluation logic - different account: alt text

AWS Policy Simulator

  • When creating new custom policies you can test it here:
  • Alternatively, you can use the CLI:
    • Some AWS CLI commands (not all) contain --dry-run option to simulate API calls. This can be used to test permissions.
    • If the command is successful, you'll get the message: Request would have succeeded, but DryRun flag is set
    • Otherwise, you'll be getting the message: An error occurred (UnauthorizedOperation) when calling the {policy_name} operation

IAM Roles vs Resource Based Policies

  • When we assume a role (user, application or service), we give up our original permission and take the permission assigned to the role
  • When using a resource based policy, principal does not have to give up any permissions
  • Example: user in account A needs to scan a DynamoDB table in account A and dump it in an S3 bucket in account B. In this case if we assume a role in account B, we wont be able to scan the table in account A => naming Account A as a principal in the resource-based policy of S3 bucket in Account B. As a result, Account A is authorized to perform any action on S3 Bucket in Account B

Best practices

  • One IAM User per person ONLY
  • One IAM Role per Application
  • IAM credentials should NEVER be shared
  • Never write IAM credentials in your code.
  • Never use the ROOT account except for initial setup
  • It's best to give users the minimal amount of permissions to perform their job

STS

alt text

  • Allows to assume roles across different accounts or same accounts
  • Generates temporary credentials (sts:AssumeRole*)
  • Temporary credentials are similar to access key. They expire and they don't belong to the identity
  • Temporary credentials are requested by another identity (AWS or external - identity federation)
  • STS allows us to enable identity federation

Assume a Role with STS

  1. Define an IAM role within an account or cross-account
  2. Define which principals can access the IAM role (Trust Policy):
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}
  1. Use the AWS STS (Secure Token Service) to retrieve the IAM role we have access to (AssumeRole API)
  2. Temporary credentials can be valid between 15 minutes to 1 hour

Revoke IAM Role Temporary Credentials

alt text

  • Trust policy: specifies who can assume a role
  • Roles can be assumed by many identities
  • Everybody who assumes a role, gets the same set of permissions
  • Temporary credentials can not be cancelled, they are valid until they expire
  • Temporary credentials can last for longer time
  • In case of a credential leak, if we change the permissions for the policy, we will affect all legitimate users - not a good idea for revoking access
  • Solution:
    • Revoke all existing sessions, by applying an AWSRevokeOlderSessions inline policy to the role. This will apply to all existing sessions, sessions created afterwards will not be affected
    • We can not manually revoke credentials!

AWS Resource Access Manager - RAM

  • Allows sharing resources between AWS accounts
  • Some services may allow sharing between any AWS accounts, some allow sharing only between accounts from the same organization
  • Services needs to support RAM in order to be shared (not everything can be shared)
  • Services can be shared with principals: accounts, OU's and ORG
  • Shared resources can be accessed natively
  • There is no cost by using RAM, only the service cost may apply

Availability Zone IDs

  • A region in AWS has multiple availability zones, example: us-east-1a, us-east-1b, etc.
  • AWS rotates the name of the AZs depending on the AWS account, meaning that us-east-1a may not be the same AZ if we compare 2 accounts
  • If a failure happens on the hardware level, two accounts may see the issue being in different AZ, this may introduce a challenge in troubleshooting
  • AWS provides AZ IDs to overcome this challenge. Example of IDs: use1-az1, use1-az2
  • AZ IDs are consistent across multiple accounts

RAM Concepts

  • Owner account:
    • Owns the resource, creates a share, provides the name
    • Retains full permission over the resource shared
    • Defines the principal (AWS account, OU, entire AWS organization) with whom the share a specific resource
  • If the participant is inside an ORG with the sharing enabled, sharing is accepted automatically
  • For non ORG accounts, or sharing with AWS Organizations is not enabled, we have to accept an invite

Shared Services VPC

  • Is a VPC which provides infrastructure which can be used by other services
  • In AWS we can connect to a shared services VPC using VPC peering, Transit Gateways or using RAM
  • VPC owner can create and manage the VPC and subnets which shared with participants
  • Participants can provision services into the shared subnets, can read an reference network objects but can not modify or delete the subnets
  • Resources created by a participant account will not be visible for other participants or by the VPC owner account
  • Resources created by a participant account can be accessed from other resources created by other participant accounts because they are on the same network

AWS Service Quotas

  • Defines how much of a "thing" we can use inside of an AWS account
  • Example:
    • Number of EC2 instances at a certain times per region
    • Number of IAM users per AWS accounts
  • Services usually have a default per region quota
  • Global services may have a per account quota instead per region
  • Most services quotas can be increased as needed
  • Some service quotes can not be changed, example: number of IAM users per account (5000)
  • Service endpoint and quotas: https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html
  • Service Quotas:
    • From the console we can go to this page, where we can create dashboards for quotas we want to monitor
    • We can request quota changes from this service for certain services
    • Quote request template: we can predefine quota value request for new accounts in an AWS organization
    • We can create a CloudWatch alarm for quotas
  • Legacy method to increase quotas: create a support ticket selecting service quota increase
  • We can request service quota increase from the CLI as well. Reference API: https://awscli.amazonaws.com/v2/documentation/api/latest/reference/service-quotas/request-service-quota-increase.html

SAML 2.0 Identity Federation

alt text

  • Federation cho phép người dùng bên ngoài AWS đảm nhận vai trò tạm thời để truy cập tài nguyên AWS

  • These users assume identity provider access role

  • SAML 2.0 - Security Assertion Markup Language

  • SAML 2.0 allows to indirectly use on-premise IDs with AWS (console and CLI)

  • SAML 2.0 based identity federation is used when we have and enterprise identity provider which is SAML 2.0 compatible

  • SAML 2.0 based federation is ideal when we have an existing identity management team managing access to other services including AWS

SAML 2.0 Identity Federation Authentication Process - API Access

  • Chúng ta bắt đầu với một môi trường on-premise ở bên trái sử dụng Identity Provider và Identity Store tương thích SAML 2.0. Bên phải là một môi trường AWS được cấu hình để cho phép Identity Federation dựa trên SAML 2.0
  • Điều này thực sự có nghĩa là từ một cơ sở hạ tầng tiềm năng đó là một Identity Provider tồn tại ở phía bên trái và một SAML Identity Provider đã được tạo trong IAM ở bên phải, sự tin cậy hai chiều đã được thiết lập giữa hai bên. Vì vậy, phiên bản IAM ở bên phải đã được định cấu hình để tin cậy Identity Provider tại chỗ trong môi trường bên trái.
  • Sau đó, chúng ta có một ứng dụng, trong trường hợp này là phiên bản doanh nghiệp của ứng dụng Catagram Nó bắt đầu quá trình này bằng cách liên lạc với Identity Provider để yêu cầu quyền truy cập
  • Khi quá trình này được bắt đầu, Identity Provider truy cập vào Identity Store và xác thực yêu cầu kéo danh sách các vai trò mà danh tính được ứng dụng Catagram sử dụng có quyền truy cập. Bên trong Identity Provider, bạn đã ánh xạ danh tính vào một hoặc nhiều vai trò. Một danh tính có thể sử dụng nhiều vai trò khác nhau, và do đó, ứng dụng Catagram sẽ có một lựa chọn để chọn.
  • Bây giờ sau khi quá trình xác thực này hoàn tất và ứng dụng Catagram đã chọn một vai trò, thứ mà nó nhận lại được gọi là SAML Assertion (Xác nhận SAML). Hãy coi đây như một mã thông báo chứng minh rằng danh tính đã được xác thực. Xác nhận SAML này được AWS tin cậy.
  • Bước tiếp theo là ứng dụng giao tiếp với AWS, cụ thể là STS bằng cách sử dụng thao tác STS: AssumeRoleWithSAML và nó chuyển trong Xác nhận SAML với yêu cầu đó. Bây giờ STS chấp nhận cuộc gọi và cho phép giả định vai trò, điều này tạo ra thông tin đăng nhập AWS tạm thời được trả về ứng dụng. Những gì đã xảy ra ở đây là Xác nhận SAML về cơ bản đã được đổi lấy thông tin đăng nhập AWS tạm thời hợp lệ.
  • Và hãy nhớ rằng, chỉ có thông tin đăng nhập AWS mới có thể được sử dụng để truy cập tài nguyên AWS. Và vì vậy, ứng dụng Catagram hiện có thể sử dụng các thông tin đăng nhập tạm thời này để tương tác với các dịch vụ AWS như DynamoDB. Quá trình này yêu cầu một số cấu hình trả trước. Ở đó cần phải là sự tin cậy hai chiều được tạo ra giữa IAM và Identity Provider đang được sử dụng cho bảo mật lưu trữ này. Và khi sự tin tưởng này đã được thiết lập, AWS sẽ tôn trọng các Xác nhận SAML và sử dụng chúng làm bằng chứng xác thực và cho phép bất kỳ thông tin nhận dạng nào đang thực hiện điều này quy trình để có quyền truy cập vào thông tin xác thực tạm thời có thể được sử dụng để tương tác với AWS.
  • Bây giờ, quá trình này diễn ra ở hậu trường. Đây là kiến trúc được sử dụng nếu bạn đang phát triển các ứng dụng này theo cách riêng trong doanh nghiệp của mình. Vì vậy, nếu bạn là nhà phát triển và bạn đang muốn sử dụng Identity Federation để truy cập AWS, đây là kiểu kiến trúc mà bạn sẽ sử dụng. Giờ đây, bạn cũng có thể sử dụng Identity Federation dựa trên SAML 2.0 để cấp quyền truy cập vào bảng điều khiển AWS cho người dùng nội bộ trong doanh nghiệp. Và nhìn chung, nó sử dụng một luồng kiến trúc rất giống nhau. alt text

SAML 2.0 Identity Federation Authentication Process - AWS Console Access

  • Khi chúng ta đang sử dụng Identity Federaion dựa trên SAML để bảo mật quyền truy cập bảng điều khiển, chúng ta vẫn có môi trường tại chỗ ở bên trái và AWS ở bên phải, vẫn có cùng một Identity Provider, chẳng hạn như ADFS, nhưng lần này là do người dùng muốn. Vẫn cần phải có một sự tin cậy được định cấu hình, lần này là giữa Identity Provider và một SSO Endpoint, còn được gọi là Điểm cuối AWS SAML và nó được định cấu hình trong IAM bên trong tài khoản AWS.
  • When we are using SAML based Identity Federation to privide console access, we still have the on-premise environment on the left and AWS on the right. We still have the same Identity Provider for example, ADFS, but this time it's a user who wants to access the AWS console rather than an application interacting with AWS products and services. There still needs to be a trust configured, this time between the Identity Provider and an SSO Endpoint also known as the AWS SAML Endpoint and this is configured within IAM inside the AWS account.
  • Now to begin this process, our user BOB, browsers to our Identity Provider portal and this might look something like this URL. So this URL is for the Animals For Life ADFS server. BOB browsers to this URL and he sees a portal which he needs to interact with. Now when BOB loads this portal before he can intercat with it in any way, behind-the-scenes the Identity Provider authenticates the reqquest. Now this might mean explicitly logging in to the Identity Provider portal or it might use the fact that you're already logged in to an Active Directory domain on your local laptop or workstation and uses this authentication instead of asking you to log in agian. But in either case. you'll be presented with a list of roles that you can use based on your identity. So there might be an admin role, a normal role, or even an audititng role and all of these provide different permissions to AWS. So once you've been authenticated or once you've selected a role, the Identity Provider protal returns a SAML Assertion and instructions to point at a SAML Endpoint that operates inside AWS. Now once the client receives this information, it sends the SAML Assertion to the SAML Endpoint that you've configured in advance within AWS. And this assertion proves that you've authenticated as your identity and it provides details on the access rights that you should receive. Now on your behalf, in the backgroud, the IAM role that you've selected in the Identity Provider portal is now assumed using STS and the Endpoint receives temporary secuirty credentials on your behalf. Then at this point, it creates a sign-in URL for the AWS console which include those credentials. And it delivers those back to the client which the client then uses to access the AWS console UI. So it's a high level. This is a fairly authenticated by an Identity Provider that exists on-premisese. You're getting a SAML Assertion. This is delivered to AWS, it's exchanged for temporary security credentials which are valid to intercat with AWS resources. The only difference in this case is that the SAML Endpoint is constructing a URL which can be used to access the AWS console UI which includes those credentials. And then once that URL has been created, it's passed back to your client and your client uses it to access the AWS management console. And this all happens behind the scenes without you having any visibility of it. But the key concept to understand and the really important thing about AWS Identity Federation is that you cannot use external identities directly to access AWS resources. They have to be exchanged for valid AWS credentials. And this is how that process happens qwhen you're using a SAML 2.0 compatible Identity Provider. Now that's all of the architectural theory that I wanted to cover in this lesson. In other lessons in this section of the course, you're going to get someasdditional exposeure to other types of Identity Federation within AWS. But SAML 2.0 based Identity Federation is the one that tends to be used in larger enterprises especially those with a Windows based Identity Provider. SO that's everything that I wanted to cover. alt text

SAML 2.0 Federation

  • We need to setup trust between AWS IAM and SAML (both ways)
  • SAML 2.0 enabled web based, cross domain SSO
  • Uses the STS API: AssumeRoleWithSAML
  • It is the old way of doing federation, recommended way by AWS is to use Amazon Single Sign On (SSO)

AWS Single Sing-On - SSO

  • A way to use existing enterprise identity store with AWS
  • Allows to centrally manage SSO access to multiple AWS accounts and external business applications as well
  • Replaces the historical uses cases provided by SAML 2.0
  • Flexible Identity store: where identities are stored. Allows for external identities to be swapped with AWS credentials
  • AWS SSO supports:
    • Built-in identity store
    • AWS Managed Microsoft AD
    • On-premise Microsoft AD
    • External Identity Provider - SAML 2.0
  • AWS SSO is preferred by AWS for any "workforce" (enterprise) identity federation over the traditional SAML 2.0 based identity federation

AWS SSO Architecture

alt text

Amazon Cognito

alt text

  • Provides authentication, authorization and user management for mobile/web applications
  • Provides 2 main pieces of functionality:
    • User Pools: used for sign-in, provides a JSON Web Token (JWT) after authentication
      • User Pools do not grant access to AWS services!
      • User Pools provide user directory management and user profiles, sign-up and sing-in with customizable web UI, MFA and other security features
      • They allow social sign-in provided by Google, Apple, Facebook as well as sign in using other identity types such as SAML identity providers
    • Identity Pools: the aim of identity pool is to exchange a type of external identity for temporary AWS credentials, which can be used to access AWS resources
      • Unauthenticated Identities: identity pools can provides access to AWS services for guest users (unauthenticated users)
      • Federated Identities: authorize users to temporarily access AWS resources after they authenticated with Google, Facebook, Twitter, SAML 2.0 and event Cognito User Pools

Amazon Workspaces

  • Managed desktop as a service product (DAAS)
  • Ideal for home working
  • Similar to Citrix/Remote Desktop
  • It provides a consistent desktop accessible from anywhere, we can log off and log back in from different places, application maintaining their state
  • We can have Windows and Linux workspaces in various sizes
  • We can use commercial applications on the workspaces
  • Workspaces can be charged on monthly or hourly basis. There is an additional monthly infrastructure cost is also applied in case we are billed hourly
  • Workspaces use Directory Service (Simple, AD, AD Connector) for authentication and user management
  • Each workspace uses an ENI injected in a VPC
  • Workspaces are accessed using client software from desktop/laptop, bandwidth is included free of charge. For any other internet access from the workspaces normal VPC infrastructure is used and charged accordingly
  • Windows workspaces can access FSx and EC2 windows resources
  • Any existing hybrid network can be also utilized for accessing on-premise resources
  • Workspaces provide a system and an user volumes, both can be encrypted

Workspaces Architecture

alt text

  • Workspaces inject an ENI into customer managed VPCs, they run into AWS managed VPCs
  • Directory services also inject ENIs into customer managed VPCs for file access, etc.
  • Workspaces are not highly available by design
  • We can distribute workspaces in different AZs, but a single workspace in particular can be affected by an AZ failure

AD Connector (Directory Services)

  • AD Connector provides a pair of directory endpoints in a VPC
  • It injects ENIs (Elastic Network Interface) into to subnets in a VPC
  • Once injected AD connector appears as a native directory to other AWS instances capable of using a directory service
  • Redirects requests to an existing on-premise directory server, which means no directory data is stored in AWS
  • AD connector allows us to use AWS services which do require an AD directory (such as Workspaces) and use this with an on-premises directory service => we don't need to deploy additional AD directory in AWS
  • There are 2 sizes of directory services small and large, while there are no explicit user limits, the chosen size does impact the amount of compute allocated by AWS for the connector
  • We can use multiple connector to distribute the load
  • AD directory is placed in 2 subnets in a VPCs in different availability zones => resilient to AZ failure
  • The connector should be configured to point to at least one on-premise directory service => we need to provide account information for the connector to be able to authenticate itself
  • Requires a working network to on-premise service, otherwise wont work (private network via Direct Connect or VPN)

AD Connector Architecture

alt text

Use cases for AD Connector

  • Prof of concept projects, we don't want to move our Active Directory to AWS for it
  • We have a small infrastructure in AWS and we don't want to move the Active Directory to AWS
  • Legal/compliance reasons - we don't want to store user info in AWS
  • For larger requirements use AWS Directory Service

Ref

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Nguyễn Huy Hoàng

17 bài viết.
10 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
11 4
(Ảnh) Tại hội nghị Build 2016 diễn ra từ ngày 30/3 đến hết ngày 1/4 ở San Francisco, Microsoft đã đưa ra 7 thông báo lớn, quan trọng và mang tầm c...
Nguyễn Huy Hoàng viết hơn 4 năm trước
11 4
White
7 0
Viết code chạy một cách trơn tru ngay lần đầu tiên là một việc rất khó, thậm chí là bất khả thi. Do đó debug là một kỹ năng vô cùng quan trọng đối ...
Nguyễn Huy Hoàng viết hơn 4 năm trước
7 0
Bài viết liên quan
White
0 0
FSx FSx For Windows File Servers FSx for Windows are fully managed native Windows file servers/file shares Designed for integration with Wind...
Nguyễn Huy Hoàng viết 2 tháng trước
0 0
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
17 bài viết.
10 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!