WEBVTT 00:00.780 --> 00:04.850 Hello and welcome to this lecture on secrets in kubernetes 00:05.040 --> 00:11.290 Here we have a simple python web application that connects to MySQL database on success. 00:11.400 --> 00:13.950 The application displays a successful message. 00:14.730 --> 00:20.470 If you look closely into the code you will see the hostname username and password hardcoded. 00:20.490 --> 00:22.470 This is of course not a good idea. 00:22.950 --> 00:28.860 As we learned in the previous lecture one option would be to move these values into a conflict map the 00:28.860 --> 00:32.910 conflict map stores configuration data in plain text format. 00:32.940 --> 00:39.120 So while it would be okay to move the hostname and username into a conflict map it is definitely not 00:39.120 --> 00:41.730 the right place to store a password. 00:41.940 --> 00:48.710 This is where secrets coming secrets are used to store sensitive information like passwords or keys. 00:48.840 --> 00:55.890 They're similar to conflict maps except that they're stored in an encoded or hashed format as with conflict 00:55.890 --> 00:56.450 maps. 00:56.460 --> 01:00.090 There are two steps involved in working with secrets. 01:00.120 --> 01:05.310 First create the secret and second injected into pod. 01:05.310 --> 01:07.730 There are two ways of creating a secret. 01:07.890 --> 01:14.070 The imperative way without using a secret definition file and the declarative way by using a secret 01:14.070 --> 01:17.150 definition file with the imperative method. 01:17.220 --> 01:23.640 You can directly specify the key value pairs in the command line itself to create a secret of the given 01:23.640 --> 01:28.290 values run the kube control create secret generic command. 01:28.290 --> 01:35.220 The command is followed by the secret name and the option from literal, from literal option, is used 01:35.220 --> 01:38.630 to specify the key value pairs in the command itself. 01:38.640 --> 01:45.260 In this example we are creating a secret by the name app Secret with a key value pair db underscore 01:45.270 --> 01:52.380 MySQL Well if you wish to add additional key value pairs simply specify the from literal 01:52.380 --> 01:55.470 options multiple times. 01:55.640 --> 02:00.980 However this could get complicated when you have too many secrets to pass in another way to input the 02:00.980 --> 02:03.530 secret data is through a file. 02:03.530 --> 02:10.040 Use the from file option to specify a path to the file that contains the required data. 02:10.040 --> 02:16.440 The data from this file is read and stored under the name of the file let us now look at the declarative 02:16.440 --> 02:17.980 approach for this. 02:18.000 --> 02:22.430 We create a definition file just like how we did for the conflict map. 02:22.500 --> 02:32.670 The file has API version kind metadata and data the API version is V1 kind a secret under metadata specify 02:32.670 --> 02:34.060 the name of the secret. 02:34.170 --> 02:41.280 We will call it app Secret under data at the secret data in a key value format. 02:41.310 --> 02:47.370 However one thing we discussed about secrets was that they are used to store sensitive data and are 02:47.370 --> 02:49.200 stored in an encoded format. 02:50.170 --> 02:54.790 Here we have specified the data in plain text which is not very safe. 02:54.790 --> 03:01.450 So while creating a secret with a declarative approach you must specify the secret values in a hashed 03:01.450 --> 03:02.830 format. 03:02.830 --> 03:07.870 So you must specify the data in an encoded form like this. 03:07.870 --> 03:15.660 But how do you convert the data from plain text to an encoded format on a linux host run the command 03:15.900 --> 03:19.660 echo dash n followed by the text you're trying to convert. 03:19.800 --> 03:29.160 Which is mysql in this case and pipe that to the base64 utility to view secrets run the kube 03:29.160 --> 03:31.880 control get secrets command. 03:31.950 --> 03:37.410 This lets the newly created secret along with another secret previously created by kubernetes for 03:37.410 --> 03:42.620 its internal purposes to view more information on the newly created secret. 03:42.690 --> 03:43.890 Run the kube control. 03:43.890 --> 03:46.200 Describe secret command. 03:46.200 --> 03:53.480 This shows the attributes in the secret but hides the value themselves to view the values as well. 03:53.610 --> 03:59.930 Run the kube control get secret command with the output displayed in a Yama format using the dash 0 03:59.940 --> 04:01.080 option. 04:01.320 --> 04:04.510 You can now see the hash values as well. 04:04.530 --> 04:07.530 Now how do you decode these hashed values. 04:07.530 --> 04:15.250 Use the same base64 Command used earlier to encode it but this time add a decode option to it. 04:15.540 --> 04:21.560 Now that we have secret created let us proceed with step 2 configuring it with a pod. 04:21.630 --> 04:28.470 Here I have a simple part definition file that runs my application to inject an environment variable 04:28.680 --> 04:35.640 add a new property to the container called envfrom the envfrom property is a list so we can pass as 04:35.640 --> 04:42.130 many environment variables as required each item in the list corresponds to a secret item. 04:42.360 --> 04:48.870 Specify the name of the secret we created earlier creating the pod definition file now makes the data 04:48.990 --> 04:53.270 in the secret available as environment variables for the application. 04:54.060 --> 04:59.850 What we just saw was injecting secrets as environment variables into the pods. 04:59.850 --> 05:03.490 There are other ways to inject secrets into pods. 05:03.630 --> 05:10.470 You can inject a single environment variables or inject the whole secret as files in a volume. 05:10.470 --> 05:16.530 If you were to mount the secret as a volume in the pod each attribute in the secret is created as a 05:16.530 --> 05:20.510 file with the value of the secret as its content. 05:20.520 --> 05:26.730 In this case since we have three attributes in our secret three files are created and if we look at 05:26.730 --> 05:31.700 the contents of the db password file we see the password in it. 05:31.710 --> 05:33.180 The third for this lecture. 05:33.300 --> 05:37.560 Head over to the coding exercises and practice working with secrets.