1
00:00:00,880 --> 00:00:05,650
Unless section we installed helm and then we eventually said hey wait we need to do some additional

2
00:00:05,650 --> 00:00:08,420
setup because we're running everything on Google Cloud.

3
00:00:08,680 --> 00:00:14,710
So this little note inside the documentation says that Google Cloud community is enable something called

4
00:00:14,740 --> 00:00:16,490
are back by default.

5
00:00:16,690 --> 00:00:22,210
So the section I want to have a quick discussion on exactly what our back is and why it's going to make

6
00:00:22,210 --> 00:00:25,810
us have to change the way in which we set up all this helm and tiller stuff.

7
00:00:25,800 --> 00:00:28,090
So we're going to look at a couple of different diagrams here.

8
00:00:28,120 --> 00:00:33,010
Now I know by this point in the course you're probably thinking oh my gosh let's just deploy this thing

9
00:00:33,010 --> 00:00:33,880
and be done with it.

10
00:00:33,880 --> 00:00:39,630
And so I'm sure the fact that I threw a in here at the very end is probably making you think oh my gosh

11
00:00:39,640 --> 00:00:43,020
like why more stuff but trust me we're almost at the end.

12
00:00:43,060 --> 00:00:47,320
We just have a couple more commands to run and then we'll be able to deploy everything and we'll be

13
00:00:47,320 --> 00:00:47,920
good to go.

14
00:00:47,920 --> 00:00:50,150
So almost at the at our.

15
00:00:50,170 --> 00:00:51,690
So couple of diagrams now.

16
00:00:51,700 --> 00:00:55,140
First thing I want to remind you because it's going to be really important as we go through this.

17
00:00:55,180 --> 00:01:01,620
We just installed helme helm is a reference specifically to the helm client which is like a Selye something

18
00:01:01,630 --> 00:01:05,110
that you and I are going to issue commands to help in turn.

19
00:01:05,110 --> 00:01:08,460
It's going to take those commands and relay them off to Tiller.

20
00:01:08,560 --> 00:01:13,930
Tiller is a POD that is going to be running inside of our cluster and this POD running Tiller is going

21
00:01:13,930 --> 00:01:18,070
to attempt to make changes to the configuration of our cluster.

22
00:01:18,070 --> 00:01:25,030
In other words it's going to try to install new sets of configuration new sets of deployments new secrets

23
00:01:25,030 --> 00:01:26,570
whatever else it might be.

24
00:01:28,730 --> 00:01:28,960
All right.

25
00:01:28,970 --> 00:01:33,950
So with that in mind I now want to tell you a little bit more about our back so our banks stands for

26
00:01:34,070 --> 00:01:36,190
roll based access control.

27
00:01:36,200 --> 00:01:42,560
The purpose of our back is to limit who can access what different types of resources inside of a community's

28
00:01:42,650 --> 00:01:46,980
cluster inside of our local development environment of mini cube.

29
00:01:47,060 --> 00:01:49,480
The system was not enabled by default.

30
00:01:49,610 --> 00:01:56,420
So in our local environment essentially you and I or any pod could access the cluster directly in arbitrarily

31
00:01:56,420 --> 00:01:58,190
change configuration.

32
00:01:58,190 --> 00:02:04,130
In other words we could create a pod inside of our cluster locally the local cluster that tried to access

33
00:02:04,130 --> 00:02:10,160
the Cubanos cluster and arbitrarily create new sets of pods or new deployments or new secrets or delete

34
00:02:10,160 --> 00:02:12,360
stuff if it wanted to.

35
00:02:12,380 --> 00:02:17,810
Now as you might imagine in a production environment we generally like to kind of lock things down and

36
00:02:17,810 --> 00:02:23,180
make sure that unauthorized users or programs do not have the ability to change the configuration of

37
00:02:23,180 --> 00:02:24,010
our cluster.

38
00:02:24,230 --> 00:02:30,740
So the back system is all about making sure that we have the ability to limit who can do what's inside

39
00:02:30,740 --> 00:02:31,940
of our cluster.

40
00:02:31,940 --> 00:02:35,780
Now like I said locally with many cube our back is not enabled.

41
00:02:35,780 --> 00:02:42,760
Google Cloud and navels are back by default so in production we have to deal with this security system.

42
00:02:42,810 --> 00:02:46,770
Now the obvious thing that I want to point out here is that as I just said the purpose of Tiller is

43
00:02:46,770 --> 00:02:50,220
to attempt to modify the configuration of our cluster.

44
00:02:50,220 --> 00:02:55,350
That definitely sounds like something that might go against this rule based access control Tiller wants

45
00:02:55,350 --> 00:03:00,600
to make changes to the cluster it wants to create things delete things modify things and so we need

46
00:03:00,600 --> 00:03:05,760
to make sure that Tiller has the correct set of permissions so that it can actually make all these different

47
00:03:05,760 --> 00:03:06,860
changes.

48
00:03:06,910 --> 00:03:12,150
So when you go back over if you still have the documentation up here and you see see Tiller Andrle based

49
00:03:12,180 --> 00:03:13,990
access control for more information.

50
00:03:14,130 --> 00:03:17,910
That article right there is essentially going to say yeah we need to make sure that chillar has the

51
00:03:17,910 --> 00:03:20,060
ability to make all these different changes.

52
00:03:21,380 --> 00:03:21,640
All right.

53
00:03:21,640 --> 00:03:23,730
Now that's just the our back system.

54
00:03:23,830 --> 00:03:26,280
The system has a lot of intricacies to it.

55
00:03:26,290 --> 00:03:31,030
So I want to go a little bit deeper in and give you just a little bit more context so that you're going

56
00:03:31,030 --> 00:03:35,680
to eventually be able to understand the different commands that you and I are going to run to allow

57
00:03:35,680 --> 00:03:38,420
tiller to make changes to our cluster.

58
00:03:38,440 --> 00:03:41,950
So a couple of pieces of terminology here.

59
00:03:41,990 --> 00:03:47,380
So this is really two sets of definitions 1 2 and 3 and four.

60
00:03:47,520 --> 00:03:49,990
And the first thing on talk about is user accounts.

61
00:03:49,990 --> 00:03:56,780
Whenever you and I as human beings access or Cabernets cluster we are making use of the CUV CDL command

62
00:03:56,960 --> 00:03:59,600
to essentially change settings inside of our cluster.

63
00:03:59,900 --> 00:04:05,210
And as you can probably guess if you and I wanted to right now on our Google Cloud dashboard or the

64
00:04:05,720 --> 00:04:11,130
cloud shell right here we could do something like Cube Seitel create pod while Beaubois whatever we

65
00:04:11,130 --> 00:04:11,680
want to do.

66
00:04:11,780 --> 00:04:16,460
And we're probably not going to see any type of warning or security error saying hey you're not allowed

67
00:04:16,460 --> 00:04:17,250
to do that.

68
00:04:17,450 --> 00:04:23,630
So you and I as users have the ability to easily log in and access cubes TTL and make changes to the

69
00:04:23,630 --> 00:04:25,400
state of our cluster.

70
00:04:25,400 --> 00:04:30,590
Now we're able to do that because of our user account the user account is something that identifies

71
00:04:30,650 --> 00:04:31,960
us as a human.

72
00:04:31,970 --> 00:04:34,570
A person administering our cluster.

73
00:04:34,790 --> 00:04:40,100
If you were working in a large company that has a ton of different workers who are supposed to be administering

74
00:04:40,130 --> 00:04:45,550
a Cabernets cluster you would probably create a separate account for each of those different employees.

75
00:04:45,580 --> 00:04:48,170
And so you can keep a log of who is modifying what.

76
00:04:48,170 --> 00:04:55,290
Inside of your cluster now in a very similar fashion a service account is going to identify a pod or

77
00:04:55,290 --> 00:04:57,370
a program inside of your cluster.

78
00:04:57,630 --> 00:05:03,060
So whereas a user account belongs to a person a service account belongs to a pod or some type of process

79
00:05:03,240 --> 00:05:04,860
running in the cluster.

80
00:05:04,890 --> 00:05:09,720
Now the important thing to understand here is that a user account and a service account alone does not

81
00:05:09,780 --> 00:05:13,920
allow a user or a pod to make changes to a cluster.

82
00:05:13,920 --> 00:05:18,380
These accounts simply identify a person in the same way that your Google account.

83
00:05:18,480 --> 00:05:21,090
Just like say identifies you as a person.

84
00:05:22,130 --> 00:05:26,870
Getting the actual ability to make changes to the state of your cluster or to change configuration is

85
00:05:26,870 --> 00:05:29,430
granted by these roll bindings.

86
00:05:29,450 --> 00:05:35,640
So the role bindings are all about authorization a role binding allows you to actually do something.

87
00:05:35,900 --> 00:05:41,360
We create role bindings and then we assign them to either a user account or a service account.

88
00:05:41,360 --> 00:05:45,240
So a user account just a user account or service account identifies you.

89
00:05:45,290 --> 00:05:51,140
It is only a role binding that gives you the ability to do something when there's two types of role

90
00:05:51,140 --> 00:05:56,780
bindings a cluster rebinding and a role binding oath that will allow you to have an authorized set of

91
00:05:56,780 --> 00:05:59,020
actions that you can make inside of your cluster.

92
00:05:59,030 --> 00:06:04,510
The only difference between them is that a cluster allows you to make changes across the entire cluster.

93
00:06:04,610 --> 00:06:09,710
So everything inside the entire cluster you can make changes to through the use of a cluster a binding

94
00:06:10,340 --> 00:06:11,120
a role binding.

95
00:06:11,150 --> 00:06:16,790
On the other hand is only going to allow you to do a certain set of actions in a single namespace.

96
00:06:16,790 --> 00:06:21,640
Now we haven't spoken about name spaces too much inside this course but as you might guess by the name

97
00:06:21,680 --> 00:06:26,870
and a little bit that we have discussed about them whenever you create a cluster we'll do a command

98
00:06:26,870 --> 00:06:27,580
right now.

99
00:06:27,710 --> 00:06:34,210
DTL get name spaces some number of name spaces get created for you automatically.

100
00:06:34,430 --> 00:06:36,600
So by default we always get default.

101
00:06:36,620 --> 00:06:42,740
Q. Public and cube system cube system contains a bunch of different Coover Nettie's objects that make

102
00:06:42,740 --> 00:06:45,060
your entire cluster work the way you expect.

103
00:06:45,080 --> 00:06:49,520
So keep system is essentially an administration level that makes sure that everything is doing what

104
00:06:49,520 --> 00:06:50,690
it's supposed to be doing.

105
00:06:50,870 --> 00:06:56,510
If you want to you can isolate different sets of resources into different name spaces and so you might

106
00:06:56,600 --> 00:07:02,060
for some reason want to create a role binding that only allows a particular service account or a user

107
00:07:02,060 --> 00:07:06,310
account to make changes to objects in a single particular namespace.

108
00:07:06,320 --> 00:07:09,940
That's very much outside the realm of what you and I are doing by a huge degree.

109
00:07:09,950 --> 00:07:13,410
I just wanted you to know that that does exist.

110
00:07:13,450 --> 00:07:19,290
So for you and I we want to make sure that this Tiller thing has the ability to make changes across

111
00:07:19,290 --> 00:07:26,880
the entire cluster and it needs to be able to have those permissions assigned to some pod essentially

112
00:07:26,880 --> 00:07:28,640
or program inside of our cluster.

113
00:07:28,650 --> 00:07:33,470
So as you might guess we need to create a service account and we don't need to create a cluster roll

114
00:07:33,510 --> 00:07:37,610
binding and then tie that close to binding to that service account.

115
00:07:37,830 --> 00:07:43,500
Well then assigned the service account to that Tiller pod so that Tiller has the ability to change anything

116
00:07:43,500 --> 00:07:46,470
that it wants to across our entire cluster.

117
00:07:46,470 --> 00:07:50,500
Now if you had big concerns around security you could definitely change this up.

118
00:07:50,520 --> 00:07:55,050
You could definitely create a service account and assign it to Tiller but then instead assign it a role

119
00:07:55,050 --> 00:08:00,750
binding so that maybe Tiller is only able to make changes to a very specific namespace but for you and

120
00:08:00,750 --> 00:08:03,540
I we want to allow tiller to do anything it wants.

121
00:08:03,540 --> 00:08:08,070
So we're going to give it a cluster roll binding that says essentially here you go do whatever you want.

122
00:08:08,070 --> 00:08:10,130
Across the entire cluster.

123
00:08:10,590 --> 00:08:10,790
OK.

124
00:08:10,800 --> 00:08:12,680
So with that in mind let's take a quick pause right here.

125
00:08:12,690 --> 00:08:16,860
When we come back the next section we're going to run to commands that are going to create the service

126
00:08:16,860 --> 00:08:18,790
account and our cluster binding.

127
00:08:18,800 --> 00:08:20,560
So a quick pause and I'll see you in just a minute.