1
00:00:06,600 --> 00:00:09,470
- Now let's take some
time to understand roles.

2
00:00:09,470 --> 00:00:12,430
Within AWS, a really powerful mechanism

3
00:00:12,430 --> 00:00:15,760
for delegating permissions are roles,

4
00:00:15,760 --> 00:00:17,260
and before we can understand roles,

5
00:00:17,260 --> 00:00:18,380
let's first take a moment

6
00:00:18,380 --> 00:00:21,060
to understand why we want to use them.

7
00:00:21,060 --> 00:00:25,480
Let's talk about anti-patterns,
credential anti-patterns.

8
00:00:25,480 --> 00:00:28,760
And so some of the things
that we don't want to do,

9
00:00:28,760 --> 00:00:31,700
the things that we would
like to avoid would be things

10
00:00:31,700 --> 00:00:34,570
like embedding access keys in our code.

11
00:00:34,570 --> 00:00:39,570
Remember, we talked about how
users can create access keys

12
00:00:41,070 --> 00:00:43,360
and then we can use those access keys

13
00:00:43,360 --> 00:00:46,290
to configure our local
development environments,

14
00:00:46,290 --> 00:00:49,910
so that we can manage AWS
from our local machines.

15
00:00:49,910 --> 00:00:54,320
Those long-term access keys
should never be embedded

16
00:00:54,320 --> 00:00:57,430
within code, because by doing so,

17
00:00:57,430 --> 00:00:59,120
there's a number of issues with that.

18
00:00:59,120 --> 00:01:00,890
By embedding them in code,

19
00:01:00,890 --> 00:01:03,820
or even within environment variables,

20
00:01:03,820 --> 00:01:07,410
now we run the risk of those
credentials being exposed

21
00:01:07,410 --> 00:01:09,970
and being seen by other people.

22
00:01:09,970 --> 00:01:11,550
I've heard of scenarios,

23
00:01:11,550 --> 00:01:14,330
I've read reports, and
even have friends of mine

24
00:01:14,330 --> 00:01:15,163
where this has happened

25
00:01:15,163 --> 00:01:20,130
where credentials have
been committed into repos

26
00:01:21,640 --> 00:01:24,520
and into public repos, like on GitHub,

27
00:01:24,520 --> 00:01:26,480
and as a result, people out there,

28
00:01:26,480 --> 00:01:29,610
who knows who, found those credentials.

29
00:01:29,610 --> 00:01:32,470
In fact, there are bots out there

30
00:01:32,470 --> 00:01:37,020
that are designed to scan
public repositories looking

31
00:01:37,020 --> 00:01:38,830
for credentials, right,

32
00:01:38,830 --> 00:01:41,420
and so I've read stories

33
00:01:41,420 --> 00:01:46,420
of developers exposing
credentials within public repos

34
00:01:48,170 --> 00:01:53,170
and then being surprised by an Amazon bill

35
00:01:54,530 --> 00:01:56,120
at the end of the month that's thousands

36
00:01:56,120 --> 00:01:58,420
of dollars beyond what they normally pay,

37
00:01:58,420 --> 00:02:00,410
because people used those credentials

38
00:02:00,410 --> 00:02:03,270
to create very expensive resources.

39
00:02:03,270 --> 00:02:04,940
And so the other aspect

40
00:02:04,940 --> 00:02:06,610
is that people have used credentials

41
00:02:06,610 --> 00:02:09,460
to delete resources, right?

42
00:02:09,460 --> 00:02:11,330
Another perspective on that

43
00:02:11,330 --> 00:02:13,780
is that it could be that members

44
00:02:13,780 --> 00:02:17,580
of your team find those
credentials that are embedded

45
00:02:17,580 --> 00:02:21,760
and end up using them in ways
that they weren't intended,

46
00:02:21,760 --> 00:02:23,680
even if it's not malicious.

47
00:02:23,680 --> 00:02:26,170
They're just being used for purposes

48
00:02:26,170 --> 00:02:27,800
that they shouldn't be used for,

49
00:02:27,800 --> 00:02:31,710
right, so we really want
to avoid embedding our code

50
00:02:31,710 --> 00:02:33,760
or embedding our credentials within code

51
00:02:33,760 --> 00:02:35,780
or within environment variables.

52
00:02:35,780 --> 00:02:38,510
The other logistical challenge

53
00:02:38,510 --> 00:02:41,230
with embedding credentials within our code

54
00:02:41,230 --> 00:02:45,670
is that now if we want to
rotate those credentials,

55
00:02:45,670 --> 00:02:47,840
like we should be doing regularly,

56
00:02:47,840 --> 00:02:51,870
we have to recommit, repush,

57
00:02:51,870 --> 00:02:54,310
remerge, retest, rebuild,

58
00:02:54,310 --> 00:02:57,200
redeploy code just to rotate credentials,

59
00:02:57,200 --> 00:02:59,080
and that's not really a good reason

60
00:02:59,080 --> 00:03:00,200
to go through all of that.

61
00:03:00,200 --> 00:03:01,713
We have a better mechanism.

62
00:03:02,650 --> 00:03:04,740
And so another thing that we don't

63
00:03:04,740 --> 00:03:06,930
want to do is share credentials.

64
00:03:06,930 --> 00:03:09,210
If you have an organization,

65
00:03:09,210 --> 00:03:14,210
and members of your organization
need to access Amazon,

66
00:03:14,330 --> 00:03:16,980
then each member should
have their own credentials,

67
00:03:16,980 --> 00:03:18,550
right, so we don't want

68
00:03:18,550 --> 00:03:20,650
to share credentials with third parties.

69
00:03:20,650 --> 00:03:24,000
We don't want to have
to create dummy users

70
00:03:24,000 --> 00:03:25,613
in order to share credentials.

71
00:03:26,780 --> 00:03:28,950
We certainly don't want to share one set

72
00:03:28,950 --> 00:03:32,680
of credentials with hundreds
of enterprise users,

73
00:03:32,680 --> 00:03:35,370
and we don't want to share credentials

74
00:03:35,370 --> 00:03:39,160
with potentially millions
of web or application users,

75
00:03:39,160 --> 00:03:43,870
right, so imagine deploying
a web or mobile application.

76
00:03:43,870 --> 00:03:47,190
By embedding credentials
in that application, you

77
00:03:47,190 --> 00:03:50,480
are essentially sharing those
credentials across millions,

78
00:03:50,480 --> 00:03:52,490
potentially millions of users.

79
00:03:52,490 --> 00:03:55,010
We have other mechanisms to handle that.

80
00:03:55,010 --> 00:03:59,040
And so, the best practices
for credentials in this regard

81
00:03:59,040 --> 00:04:04,040
to avoid those things would be
to use temporary credentials,

82
00:04:04,170 --> 00:04:07,830
and we can delegate permissions to,

83
00:04:07,830 --> 00:04:09,960
for example, an EC2 instance.

84
00:04:09,960 --> 00:04:12,950
So instead of embedding our
credentials in our code,

85
00:04:12,950 --> 00:04:16,160
and then deploying code to that instance,

86
00:04:16,160 --> 00:04:18,980
if we instead give the instance a way

87
00:04:18,980 --> 00:04:23,030
to retrieve permission
or retrieve credentials,

88
00:04:23,030 --> 00:04:27,410
then we can provide our
application away to retrieve,

89
00:04:27,410 --> 00:04:29,940
automatically retrieve credentials

90
00:04:29,940 --> 00:04:31,750
that automatically expire,

91
00:04:31,750 --> 00:04:33,760
and then get automatically renewed.

92
00:04:33,760 --> 00:04:38,730
And so we can delegate
permissions to EC2 instances,

93
00:04:38,730 --> 00:04:41,530
to other Amazon services.

94
00:04:41,530 --> 00:04:45,300
We can grant users within
our own account the ability

95
00:04:45,300 --> 00:04:48,650
to temporarily elevate their privileges,

96
00:04:48,650 --> 00:04:52,910
or we can grant permissions
to a separate account,

97
00:04:52,910 --> 00:04:56,260
and that separate account
could be one that you own,

98
00:04:56,260 --> 00:04:58,180
or it could be a third-party.

99
00:04:58,180 --> 00:05:02,280
It's really common for
organizations within AWS

100
00:05:02,280 --> 00:05:04,610
to have multiple accounts.

101
00:05:04,610 --> 00:05:06,330
And it could be that you

102
00:05:06,330 --> 00:05:09,660
have an account dedicated for development,

103
00:05:09,660 --> 00:05:10,540
and it could be that you

104
00:05:10,540 --> 00:05:13,480
have an account dedicated for production.

105
00:05:13,480 --> 00:05:15,590
Or different business departments

106
00:05:15,590 --> 00:05:19,720
or business units may
have their own accounts

107
00:05:19,720 --> 00:05:23,120
in order to achieve
some type of isolation,

108
00:05:23,120 --> 00:05:26,330
secure isolation, between
different things, right?

109
00:05:26,330 --> 00:05:28,910
And so using cross-account roles allows us

110
00:05:28,910 --> 00:05:30,320
to log into one account

111
00:05:30,320 --> 00:05:34,300
and then temporarily gain
access into another account.

112
00:05:34,300 --> 00:05:35,630
That also works really well

113
00:05:35,630 --> 00:05:38,110
for client/vendor relationships, right?

114
00:05:38,110 --> 00:05:40,560
So take myself for an example.

115
00:05:40,560 --> 00:05:44,650
When I'm not teaching classes
or not recording videos,

116
00:05:44,650 --> 00:05:49,070
I'm consulting, and when
I work with clients,

117
00:05:49,070 --> 00:05:52,610
I tell them, hey, you don't
need to create a user for me,

118
00:05:52,610 --> 00:05:54,560
I already have a user, and

119
00:05:54,560 --> 00:05:57,800
one of the least secure things
you can do is create a user

120
00:05:57,800 --> 00:06:00,810
and then email me the
username and password.

121
00:06:00,810 --> 00:06:02,900
That's exactly the kind
of thing we want to avoid.

122
00:06:02,900 --> 00:06:07,900
Instead, create a role for
me and then email me the id

123
00:06:10,682 --> 00:06:12,290
of that role, and then that way,

124
00:06:12,290 --> 00:06:17,000
I can assume that role and
gain access into your account.

125
00:06:17,000 --> 00:06:19,430
And we will talk about how

126
00:06:19,430 --> 00:06:22,463
to do those things in upcoming lessons.