Unless section we installed helm and then we eventually said hey wait we need to do some additional
setup because we're running everything on Google Cloud.
So this little note inside the documentation says that Google Cloud community is enable something called
are back by default.
So the section I want to have a quick discussion on exactly what our back is and why it's going to make
us have to change the way in which we set up all this helm and tiller stuff.
So we're going to look at a couple of different diagrams here.
Now I know by this point in the course you're probably thinking oh my gosh let's just deploy this thing
and be done with it.
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
like why more stuff but trust me we're almost at the end.
We just have a couple more commands to run and then we'll be able to deploy everything and we'll be
good to go.
So almost at the at our.
So couple of diagrams now.
First thing I want to remind you because it's going to be really important as we go through this.
We just installed helme helm is a reference specifically to the helm client which is like a Selye something
that you and I are going to issue commands to help in turn.
It's going to take those commands and relay them off to Tiller.
Tiller is a POD that is going to be running inside of our cluster and this POD running Tiller is going
to attempt to make changes to the configuration of our cluster.
In other words it's going to try to install new sets of configuration new sets of deployments new secrets
whatever else it might be.
All right.
So with that in mind I now want to tell you a little bit more about our back so our banks stands for
roll based access control.
The purpose of our back is to limit who can access what different types of resources inside of a community's
cluster inside of our local development environment of mini cube.
The system was not enabled by default.
So in our local environment essentially you and I or any pod could access the cluster directly in arbitrarily
change configuration.
In other words we could create a pod inside of our cluster locally the local cluster that tried to access
the Cubanos cluster and arbitrarily create new sets of pods or new deployments or new secrets or delete
stuff if it wanted to.
Now as you might imagine in a production environment we generally like to kind of lock things down and
make sure that unauthorized users or programs do not have the ability to change the configuration of
our cluster.
So the back system is all about making sure that we have the ability to limit who can do what's inside
of our cluster.
Now like I said locally with many cube our back is not enabled.
Google Cloud and navels are back by default so in production we have to deal with this security system.
Now the obvious thing that I want to point out here is that as I just said the purpose of Tiller is
to attempt to modify the configuration of our cluster.
That definitely sounds like something that might go against this rule based access control Tiller wants
to make changes to the cluster it wants to create things delete things modify things and so we need
to make sure that Tiller has the correct set of permissions so that it can actually make all these different
changes.
So when you go back over if you still have the documentation up here and you see see Tiller Andrle based
access control for more information.
That article right there is essentially going to say yeah we need to make sure that chillar has the
ability to make all these different changes.
All right.
Now that's just the our back system.
The system has a lot of intricacies to it.
So I want to go a little bit deeper in and give you just a little bit more context so that you're going
to eventually be able to understand the different commands that you and I are going to run to allow
tiller to make changes to our cluster.
So a couple of pieces of terminology here.
So this is really two sets of definitions 1 2 and 3 and four.
And the first thing on talk about is user accounts.
Whenever you and I as human beings access or Cabernets cluster we are making use of the CUV CDL command
to essentially change settings inside of our cluster.
And as you can probably guess if you and I wanted to right now on our Google Cloud dashboard or the
cloud shell right here we could do something like Cube Seitel create pod while Beaubois whatever we
want to do.
And we're probably not going to see any type of warning or security error saying hey you're not allowed
to do that.
So you and I as users have the ability to easily log in and access cubes TTL and make changes to the
state of our cluster.
Now we're able to do that because of our user account the user account is something that identifies
us as a human.
A person administering our cluster.
If you were working in a large company that has a ton of different workers who are supposed to be administering
a Cabernets cluster you would probably create a separate account for each of those different employees.
And so you can keep a log of who is modifying what.
Inside of your cluster now in a very similar fashion a service account is going to identify a pod or
a program inside of your cluster.
So whereas a user account belongs to a person a service account belongs to a pod or some type of process
running in the cluster.
Now the important thing to understand here is that a user account and a service account alone does not
allow a user or a pod to make changes to a cluster.
These accounts simply identify a person in the same way that your Google account.
Just like say identifies you as a person.
Getting the actual ability to make changes to the state of your cluster or to change configuration is
granted by these roll bindings.
So the role bindings are all about authorization a role binding allows you to actually do something.
We create role bindings and then we assign them to either a user account or a service account.
So a user account just a user account or service account identifies you.
It is only a role binding that gives you the ability to do something when there's two types of role
bindings a cluster rebinding and a role binding oath that will allow you to have an authorized set of
actions that you can make inside of your cluster.
The only difference between them is that a cluster allows you to make changes across the entire cluster.
So everything inside the entire cluster you can make changes to through the use of a cluster a binding
a role binding.
On the other hand is only going to allow you to do a certain set of actions in a single namespace.
Now we haven't spoken about name spaces too much inside this course but as you might guess by the name
and a little bit that we have discussed about them whenever you create a cluster we'll do a command
right now.
DTL get name spaces some number of name spaces get created for you automatically.
So by default we always get default.
Q. Public and cube system cube system contains a bunch of different Coover Nettie's objects that make
your entire cluster work the way you expect.
So keep system is essentially an administration level that makes sure that everything is doing what
it's supposed to be doing.
If you want to you can isolate different sets of resources into different name spaces and so you might
for some reason want to create a role binding that only allows a particular service account or a user
account to make changes to objects in a single particular namespace.
That's very much outside the realm of what you and I are doing by a huge degree.
I just wanted you to know that that does exist.
So for you and I we want to make sure that this Tiller thing has the ability to make changes across
the entire cluster and it needs to be able to have those permissions assigned to some pod essentially
or program inside of our cluster.
So as you might guess we need to create a service account and we don't need to create a cluster roll
binding and then tie that close to binding to that service account.
Well then assigned the service account to that Tiller pod so that Tiller has the ability to change anything
that it wants to across our entire cluster.
Now if you had big concerns around security you could definitely change this up.
You could definitely create a service account and assign it to Tiller but then instead assign it a role
binding so that maybe Tiller is only able to make changes to a very specific namespace but for you and
I we want to allow tiller to do anything it wants.
So we're going to give it a cluster roll binding that says essentially here you go do whatever you want.
Across the entire cluster.
OK.
So with that in mind let's take a quick pause right here.
When we come back the next section we're going to run to commands that are going to create the service
account and our cluster binding.
So a quick pause and I'll see you in just a minute.