1
00:00:06,376 --> 00:00:08,804
- Okay, so now let's review a use case,

2
00:00:08,804 --> 00:00:11,887
using roles for cross-account access.

3
00:00:12,780 --> 00:00:15,476
So in this use case, what we're looking at

4
00:00:15,476 --> 00:00:18,906
are leveraging multiple
accounts in one organization,

5
00:00:18,906 --> 00:00:20,977
multiple AWS accounts.

6
00:00:20,977 --> 00:00:22,867
This is a a very common practice.

7
00:00:22,867 --> 00:00:24,612
A lot of organizations will do this;

8
00:00:24,612 --> 00:00:27,545
split up different resources
between different accounts.

9
00:00:27,545 --> 00:00:29,993
This is also considered a best practice,

10
00:00:29,993 --> 00:00:32,822
and recommended by AWS to do this.

11
00:00:32,822 --> 00:00:35,340
Now, how you split your resources up

12
00:00:35,340 --> 00:00:37,381
between accounts is totally up to you.

13
00:00:37,381 --> 00:00:39,636
This is just one example,
you don't necessarily

14
00:00:39,636 --> 00:00:41,224
have to do it this way.

15
00:00:41,224 --> 00:00:43,395
But in this example,
what we're going to do

16
00:00:43,395 --> 00:00:46,101
is put our development resources over here

17
00:00:46,101 --> 00:00:49,100
in what we might call
a development account,

18
00:00:49,100 --> 00:00:50,655
and that's completely arbitrary.

19
00:00:50,655 --> 00:00:52,407
That's just what we've chosen to name it.

20
00:00:52,407 --> 00:00:54,807
Again, there's nothing
in Amazon Web Services

21
00:00:54,807 --> 00:00:57,709
that says we have to call it that.

22
00:00:57,709 --> 00:01:00,358
We're going to put our
production resources

23
00:01:00,358 --> 00:01:02,825
in a production account.

24
00:01:02,825 --> 00:01:06,992
Now, the key here is what
we call the payer account.

25
00:01:07,863 --> 00:01:10,261
So, our initial account that we opened,

26
00:01:10,261 --> 00:01:12,463
we might call that the payer account,

27
00:01:12,463 --> 00:01:15,623
and within that account,
again we will have

28
00:01:15,623 --> 00:01:18,884
no users, no groups, no roles.

29
00:01:18,884 --> 00:01:21,967
We will have no resources deployed,

30
00:01:21,967 --> 00:01:24,997
and the only thing that
we use that account for,

31
00:01:24,997 --> 00:01:27,173
is for paying the bill.

32
00:01:27,173 --> 00:01:30,072
So again, that's what we
call the payer account.

33
00:01:30,072 --> 00:01:34,140
The other two accounts are what
we call the linked accounts.

34
00:01:34,140 --> 00:01:37,546
These are the counts in which we create

35
00:01:37,546 --> 00:01:40,248
and manage our resources, and the course.

36
00:01:40,248 --> 00:01:42,243
Again the payer account
is just the account

37
00:01:42,243 --> 00:01:44,512
we use to pay the bill.

38
00:01:44,512 --> 00:01:47,770
So again, here in the development account,

39
00:01:47,770 --> 00:01:49,757
just one way to use this, is here

40
00:01:49,757 --> 00:01:53,229
we would add our users,
our groups, and our roles.

41
00:01:53,229 --> 00:01:55,823
We would add our development resources,

42
00:01:55,823 --> 00:01:59,458
and in the production account,
we won't have any users.

43
00:01:59,458 --> 00:02:01,306
So, no users or groups.

44
00:02:01,306 --> 00:02:04,276
In order to get access into production,

45
00:02:04,276 --> 00:02:07,166
we will leverage roles, and we're going to

46
00:02:07,166 --> 00:02:11,601
review an example of how
to do that coming up.

47
00:02:11,601 --> 00:02:13,249
Now, the way that you link these accounts

48
00:02:13,249 --> 00:02:14,561
are completely up to you.

49
00:02:14,561 --> 00:02:16,742
You might separate further into

50
00:02:16,742 --> 00:02:18,198
different types of environments.

51
00:02:18,198 --> 00:02:20,527
You might have an account for QA,

52
00:02:20,527 --> 00:02:22,250
an account for testing.

53
00:02:22,250 --> 00:02:25,545
You might split them by
department or business unit.

54
00:02:25,545 --> 00:02:29,042
Perhaps you want finance and
accounting, resources in one.

55
00:02:29,042 --> 00:02:32,068
You might want engineering
or research and development

56
00:02:32,068 --> 00:02:33,694
resources in another one.

57
00:02:33,694 --> 00:02:35,863
Again, it's completely up to you.

58
00:02:35,863 --> 00:02:37,927
Now, moving forward from this example,

59
00:02:37,927 --> 00:02:39,276
what we're going to look at is how

60
00:02:39,276 --> 00:02:41,312
this actually continues to work

61
00:02:41,312 --> 00:02:44,375
at the user and role level.

62
00:02:44,375 --> 00:02:48,375
So in our development
account, we have our user.

63
00:02:49,787 --> 00:02:53,470
In this particular case,
our user is jane.doe,

64
00:02:53,470 --> 00:02:56,746
and in our production
account, notice we have

65
00:02:56,746 --> 00:02:59,249
a separate account number up here.

66
00:02:59,249 --> 00:03:00,748
We have a role.

67
00:03:00,748 --> 00:03:02,867
So again, in our
production account, in this

68
00:03:02,867 --> 00:03:04,816
particular example, we will not have

69
00:03:04,816 --> 00:03:07,609
any users over here; we just have a role.

70
00:03:07,609 --> 00:03:11,401
So, when Jane wants to do
things, perform actions

71
00:03:11,401 --> 00:03:15,825
on production resources,
what she will need to do

72
00:03:15,825 --> 00:03:19,247
is assume a role in order to do that.

73
00:03:19,247 --> 00:03:22,229
So, here we have a role called admin.

74
00:03:22,229 --> 00:03:26,407
You can see that this role
in this particular example,

75
00:03:26,407 --> 00:03:29,605
it's allowed to terminate ec2 instances,

76
00:03:29,605 --> 00:03:32,938
but only in perhaps a particular region.

77
00:03:34,716 --> 00:03:35,969
Whatever region that is.

78
00:03:35,969 --> 00:03:40,052
Maybe it's only in US
west, and it's not US east.

79
00:03:41,354 --> 00:03:44,529
We also have what we call
a trust relationship.

80
00:03:44,529 --> 00:03:47,221
Essentially what we're saying is that

81
00:03:47,221 --> 00:03:51,093
when we create this role
for cross-account access,

82
00:03:51,093 --> 00:03:54,926
we're going to specify
that we are trusting...

83
00:03:56,388 --> 00:03:59,940
Again, we're trusting
the development account

84
00:03:59,940 --> 00:04:03,940
as an account that we
allow to assume that role.

85
00:04:05,013 --> 00:04:06,567
What we're also going to do is

86
00:04:06,567 --> 00:04:09,371
give this user, we're giving Jane Doe

87
00:04:09,371 --> 00:04:11,778
the ability to assume that role.

88
00:04:11,778 --> 00:04:14,067
So you can see here that we're going

89
00:04:14,067 --> 00:04:16,577
to allow her to assume that role,

90
00:04:16,577 --> 00:04:19,744
and notice that we are specifying here

91
00:04:21,296 --> 00:04:24,793
the account number of the production role.

92
00:04:24,793 --> 00:04:27,116
So, again, what we have as a user

93
00:04:27,116 --> 00:04:30,949
in our development
account, is assuming a role

94
00:04:32,280 --> 00:04:35,714
that is trusted by the production account,

95
00:04:35,714 --> 00:04:37,938
and once Jane Doe assumes that role,

96
00:04:37,938 --> 00:04:41,170
she will then be allowed
to perform these actions

97
00:04:41,170 --> 00:04:44,076
on resources within
the production account.

98
00:04:44,076 --> 00:04:47,017
So let's look at how this actually works.

99
00:04:47,017 --> 00:04:50,712
Our user Jane Doe, in
this particular example

100
00:04:50,712 --> 00:04:54,045
will use the AWS command line tools

101
00:04:55,503 --> 00:04:58,253
to assume this particular role.

102
00:04:59,351 --> 00:05:01,232
So, we're using the STS service,

103
00:05:01,232 --> 00:05:03,147
the security token service, and we're

104
00:05:03,147 --> 00:05:05,563
calling the action "assume role."

105
00:05:05,563 --> 00:05:08,155
And, as we've seen, we've already given

106
00:05:08,155 --> 00:05:10,164
the Jane Doe user the permission

107
00:05:10,164 --> 00:05:12,382
to perform this particular action.

108
00:05:12,382 --> 00:05:14,556
So, she's calling the
security token service

109
00:05:14,556 --> 00:05:18,091
saying, I want to assume the admin role

110
00:05:18,091 --> 00:05:20,037
in the production account.

111
00:05:20,037 --> 00:05:22,375
The security token service will return,

112
00:05:22,375 --> 00:05:26,542
again, temporary credentials
to the Jane Doe user,

113
00:05:29,611 --> 00:05:33,163
then she can use those
temporary credentials

114
00:05:33,163 --> 00:05:34,807
to perform another action.

115
00:05:34,807 --> 00:05:37,253
In this particular case, perhaps Jane

116
00:05:37,253 --> 00:05:39,265
has determined that she needs to terminate

117
00:05:39,265 --> 00:05:41,931
a particular instance in
the production account.

118
00:05:41,931 --> 00:05:45,513
So again, she might use
the AWS command line tools,

119
00:05:45,513 --> 00:05:48,871
leveraging the ec2 service to terminate

120
00:05:48,871 --> 00:05:53,038
instances, leveraging these
temporary credentials.

121
00:05:54,084 --> 00:05:56,843
And in doing so, she can then terminate

122
00:05:56,843 --> 00:05:59,095
this particular ec2 instance.

123
00:05:59,095 --> 00:06:02,873
So again, that's just one
example of leveraging roles

124
00:06:02,873 --> 00:06:05,706
to allow a user in one account to

125
00:06:07,166 --> 00:06:10,391
access resources in another account.

126
00:06:10,391 --> 00:06:12,326
And perhaps you do that,

127
00:06:12,326 --> 00:06:14,251
it could be an account that you own.

128
00:06:14,251 --> 00:06:16,184
It could be a third-party account, such as

129
00:06:16,184 --> 00:06:19,429
a customer or a vendor as well.

130
00:06:19,429 --> 00:06:21,915
So again, using roles
for cross-account access,

131
00:06:21,915 --> 00:06:24,481
are a really powerful and flexible way

132
00:06:24,481 --> 00:06:26,888
to achieve a higher degree of security

133
00:06:26,888 --> 00:06:30,556
within your Amazon Web
Services environment.