WEBVTT

00:01.066 --> 00:06.126
So let's go through the lab on certificates.

00:07.105 --> 00:09.888
A new member Akshay joined our team.

00:09.975 --> 00:11.689
He requires access to our cluster.

00:11.745 --> 00:13.042
The Certificate Signing Request

00:13.042 --> 00:15.408
is at the root location.

00:17.236 --> 00:18.453
See where we are.

00:18.511 --> 00:20.640
We are in root,

00:21.207 --> 00:24.887
so we have akshay.csr and akshay.key.

00:25.427 --> 00:28.528
Let's look at there in those files.

00:28.528 --> 00:30.341
This is the CSR,

00:30.349 --> 00:31.917
so Certificate Signing Request,

00:32.501 --> 00:37.481
and then here is basically the key.

00:38.448 --> 00:39.827
That's good.

00:40.004 --> 00:41.995
Create a certificate signing,

00:41.995 --> 00:44.530
request object with the name akshay

00:44.843 --> 00:47.328
with the contents of the akshay.csr file.

00:48.821 --> 00:50.249
For this we have to create--

00:50.981 --> 00:54.373
there is no imperative command,

00:55.212 --> 00:59.144
so let's go here and in the CSR

00:59.144 --> 01:01.187
or the Certificate Signing Request page

01:01.706 --> 01:02.761
on Kubernetes.

01:02.761 --> 01:05.270
We have Kubernetes documentation pages.

01:05.270 --> 01:08.305
We have this section here

01:08.320 --> 01:09.973
to create Certificate Signing Requests.

01:09.973 --> 01:13.437
We're going to get this because we want to--

01:13.699 --> 01:15.461
let's skip the first and last lines

01:15.461 --> 01:17.677
because we want to edit this request

01:17.808 --> 01:19.338
and maybe even the expiration dates

01:19.338 --> 01:22.189
because that's not required for now.

01:22.480 --> 01:27.723
I'm going to create a file called akshay.yaml.

01:28.892 --> 01:30.087
I'm going to paste that.

01:32.414 --> 01:33.313
What we need to do

01:33.323 --> 01:37.246
is pass in the csr file here.

01:37.246 --> 01:41.978
Basically, the contents of akshay.csr

01:42.213 --> 01:43.721
needs to go here, but as you can see,

01:43.721 --> 01:45.056
this is in a different format.

01:45.078 --> 01:48.722
This is basically a base64 encoded format.

01:49.010 --> 01:49.978
First, we need to get

01:49.978 --> 01:51.953
the base64 encoded format of this,

01:52.162 --> 01:54.547
and then change this and change the name

01:54.819 --> 01:56.232
and that's maybe get rid of this.

01:59.936 --> 02:01.726
Let's do that.

02:02.210 --> 02:05.847
Let's get cat akshay.csr

02:06.244 --> 02:08.523
then we pass it through base64,

02:09.393 --> 02:10.293
and then we get this.

02:10.424 --> 02:12.290
Now this command base64

02:12.290 --> 02:16.518
by default prints it in this format 

02:18.087 --> 02:19.558
with new lines.

02:20.041 --> 02:22.016
That won't work very well here

02:22.016 --> 02:25.064
because it needs to be a single line.

02:25.064 --> 02:29.793
What we're going to do is touch -W 0

02:31.149 --> 02:34.574
and that basically prints it in a single line.

02:34.892 --> 02:36.322
Then we're just going to copy this

02:36.370 --> 02:40.581
and just make sure you copy right til here,

02:42.700 --> 02:43.898
then we go in here, 

02:49.151 --> 02:52.429
so request.

02:59.173 --> 03:02.264
Let's paste that, okay.

03:04.751 --> 03:06.928
Then we got to get rid of this line.

03:07.682 --> 03:08.644
That's not required.

03:09.001 --> 03:12.361
Then we have the metadata here

03:13.027 --> 03:18.407
and this is akshay, but also,

03:19.364 --> 03:20.416
so the signer name.

03:24.943 --> 03:26.574
The signer name should be

03:26.574 --> 03:28.848
kubernetes.iokube-apiserver-client.

03:28.848 --> 03:30.884
It's already kube-apiserver-client.

03:32.853 --> 03:33.929
This is good.

03:37.066 --> 03:39.815
Save that and let's create.

03:45.376 --> 03:49.670
It looks like there is an error.

03:52.540 --> 03:56.843
This is illegal base64 data at input 500.

03:56.843 --> 03:57.912
Let's take a look.

04:03.073 --> 04:03.990
If you look here,

04:04.084 --> 04:07.776
I think we missed an equal sign.

04:08.080 --> 04:09.464
Let's just do that again.

04:10.021 --> 04:11.006
You copy that 

04:15.878 --> 04:17.776
and request.

04:20.795 --> 04:22.220
That seems to be good,

04:27.180 --> 04:29.432
is going to align that correctly

04:29.956 --> 04:31.757
and let's save this

04:32.606 --> 04:35.095
and let's create that file again.

04:35.920 --> 04:39.132
That's done to get CSR.

04:42.240 --> 04:44.930
The CSR request named actually is created

04:45.316 --> 04:49.515
and you can see it's in pending state.

04:49.663 --> 04:50.509
Let's give this a shot.

04:50.918 --> 04:52.016
That's successful.

04:52.271 --> 04:55.127
What is the condition of the newly created

04:55.127 --> 04:56.608
Certificate Signing Request object?

04:56.608 --> 04:59.566
It's in a pending state select pending.

05:02.433 --> 05:05.369
Now we've got approve the CSR requests,

05:05.369 --> 05:11.776
so let's do a kubectl certificate approve

05:12.220 --> 05:13.760
and then the name.

05:14.720 --> 05:18.494
That's approved and we see that

05:18.589 --> 05:20.707
it's indeed approved.

05:24.055 --> 05:25.195
Now how many CSR requests

05:25.195 --> 05:26.455
are available on the cluster?

05:26.504 --> 05:27.355
So if you look at this,

05:27.355 --> 05:29.391
we have two requests.

05:34.077 --> 05:36.087
Okay, so during a routine check

05:36.109 --> 05:38.271
you realize that there is a new CSR request,

05:38.271 --> 05:39.745
what is the name of this request?

05:40.174 --> 05:41.304
Let's look at that again.

05:41.304 --> 05:42.647
So we see that there is indeed

05:42.647 --> 05:44.775
a new request that's come in

05:44.775 --> 05:46.412
and it's called agent-smith.

05:47.481 --> 05:49.413
Okay, so it's called agent-smith.

05:53.272 --> 05:56.276
Now you're not aware of a request coming in.

05:57.209 --> 05:58.804
What groups is the CSR 

05:58.804 --> 05:59.970
requesting access to?

06:00.218 --> 06:02.242
So you see that there's a request and now--

06:02.278 --> 06:05.323
let's see what groups

06:05.752 --> 06:07.762
it's requesting access to.

06:07.762 --> 06:12.836
So we could do a kubectl get CSR agent-smith

06:12.863 --> 06:17.146
and then do view it in yamal format,

06:17.493 --> 06:18.967
that way we get more details

06:19.335 --> 06:22.128
and here you see under the spec section here,

06:22.128 --> 06:23.607
groups and is requesting

06:23.607 --> 06:24.773
for system masters,

06:24.790 --> 06:26.009
system authenticated.

06:28.470 --> 06:30.453
System masters is one

06:30.453 --> 06:35.030
that is requesting access to.

06:35.216 --> 06:37.083
Select system masters.

06:40.722 --> 06:41.944
Now that doesn't look very right,

06:41.944 --> 06:44.678
because we don't want to give system masters,

06:44.678 --> 06:48.135
which is the group which has an access

06:48.135 --> 06:52.320
to a group that has a lot of powers.

06:52.353 --> 06:53.360
We don't want to do that,

06:53.360 --> 06:55.025
so we want to reject that.

06:55.294 --> 06:58.155
Let's do a kubectl certificate

06:58.380 --> 07:02.181
deny agent-smith.

07:05.078 --> 07:05.696
Okay.

07:08.186 --> 07:09.871
Next, let's get rid of it,

07:09.871 --> 07:11.469
delete the new CSR object.

07:11.932 --> 07:14.046
Let's see the status now

07:15.190 --> 07:16.705
and we see that it's denied

07:17.008 --> 07:18.244
and we want to now get rid of it.

07:18.244 --> 07:24.048
We'll do a kubectl delete CSR agent-smith.

07:25.726 --> 07:27.886
Okay, so that should now be gone.

07:29.566 --> 07:30.312
Check it again,

07:30.349 --> 07:32.067
yes and that's indeed gone.

07:32.647 --> 07:35.183
 Okay so that's the end of this lab.