1 00:00:00,800 --> 00:00:08,260 Hello and welcome to this lecture on secrets in Kubernetes. Here we have a simple python web application 2 00:00:08,380 --> 00:00:12,010 that connects to a mysql database. On success 3 00:00:12,010 --> 00:00:15,340 the application displays a successful message. 4 00:00:15,340 --> 00:00:21,080 If you look closely into the code you will see the hostname username and password hardcoded. 5 00:00:21,100 --> 00:00:23,490 This is of course not a good idea. 6 00:00:23,560 --> 00:00:29,470 As we learned in the previous lecture, one option would be to move these values into a configMap. The 7 00:00:29,470 --> 00:00:33,510 configMap stores configuration data in plain text format. 8 00:00:33,550 --> 00:00:39,730 So while it would be okay to move the hostname and username into a configMap it is definitely not 9 00:00:39,730 --> 00:00:42,520 the right place to store a password. 10 00:00:42,530 --> 00:00:49,460 This is where secrets coming secrets are used to store sensitive information like passwords or keys. 11 00:00:49,460 --> 00:00:56,480 They're similar to configMap except that they're stored in an encoded or hashed format as with config 12 00:00:56,480 --> 00:00:57,070 maps. 13 00:00:57,080 --> 00:01:00,740 There are two steps involved in working with secrets. 14 00:01:00,740 --> 00:01:05,930 First create the secret and second injected into pod. 15 00:01:05,930 --> 00:01:08,330 There are two ways of creating a secret. 16 00:01:08,480 --> 00:01:14,660 The imperative way - without using a Secret definition file and the Declarative way by using a Secret 17 00:01:14,660 --> 00:01:17,750 definition file with the imperative method. 18 00:01:17,810 --> 00:01:24,260 You can directly specify the key value pairs in the command line itself to create a secret of the given 19 00:01:24,260 --> 00:01:28,910 values, run the kubectl create secret generic command. 20 00:01:28,910 --> 00:01:35,930 The command is followed by the secret name and the option –from-literal. The from literal option is used to 21 00:01:35,930 --> 00:01:39,250 specify the key value pairs in the command itself. 22 00:01:39,260 --> 00:01:45,890 In this example, we are creating a secret by the name app-secret, with a key value pair 23 00:01:45,890 --> 00:01:52,970 DB_Host=mysql. If you wish to add additional key value pairs, simply specify the from literal 24 00:01:52,970 --> 00:02:00,080 options multiple times however this could get complicated when you have too many secrets to pass in 25 00:02:00,480 --> 00:02:04,000 another way to input the secret data is through a file. 26 00:02:04,140 --> 00:02:10,480 Use the –from-file option to specify a path to the file that contains the required data. 27 00:02:10,650 --> 00:02:17,040 The data from this file is read and stored under the name of the file let us now look at the declarative 28 00:02:17,040 --> 00:02:18,030 approach. 29 00:02:18,030 --> 00:02:23,100 For this we create a definition file, just like how we did for the ConfigMap. 30 00:02:23,100 --> 00:02:33,290 The file has apiVersion, kind, metadata and data. The apiVersion is v1, kind is Secret. Under metadata specify 31 00:02:33,290 --> 00:02:34,650 the name of the secret. 32 00:02:34,790 --> 00:02:41,010 We will call it app-secret. Under data add the secret data in a key-value format. 33 00:02:41,900 --> 00:02:48,350 However one thing we discussed about secrets was that there used to store sensitive data and are stored 34 00:02:48,440 --> 00:02:50,770 in an encoded format. 35 00:02:50,780 --> 00:02:55,400 Here we have specified the data in plain text which is not very safe. 36 00:02:55,400 --> 00:03:02,060 So while creating a secret with a declarative approach you must specify the secret values in a hashed 37 00:03:02,060 --> 00:03:03,440 format. 38 00:03:03,440 --> 00:03:07,550 So you must specify the data in an encoded form like this. 39 00:03:08,480 --> 00:03:16,430 But how do you convert the data from plain text to an encoded format on a linux host from the command. 40 00:03:16,500 --> 00:03:23,370 echo –n followed by the text you are trying to convert, which is mysql in this case and pipe 41 00:03:23,400 --> 00:03:33,180 that to the base64 utility. To view secrets run the kubectl get secrets command. This lists 42 00:03:33,180 --> 00:03:38,570 the newly created secret along with another secret previously created by kubernetes for its internal 43 00:03:38,570 --> 00:03:43,240 purposes to view more information on the newly created secret. 44 00:03:43,290 --> 00:03:46,790 run the kubectl describe secret command. 45 00:03:46,810 --> 00:03:54,090 This shows the attributes in the secret but hides the value themselves to view the values as well. 46 00:03:54,220 --> 00:04:00,220 run the kubectl get secret command with the output displayed in a YAML format using the 47 00:04:00,310 --> 00:04:01,650 –o option. 48 00:04:01,930 --> 00:04:04,120 You can now see the hashed values as well. 49 00:04:05,120 --> 00:04:07,930 Now how do you decode these hashed values. 50 00:04:08,150 --> 00:04:15,140 Use the same base64 Command used earlier to encode it but this time add a decode option to it. 51 00:04:16,160 --> 00:04:22,140 Now that we have secret created let us proceed with step 2 configuring it with a pod. 52 00:04:22,250 --> 00:04:26,000 Here I have a simple pod definition file that runs my application. 53 00:04:27,350 --> 00:04:33,710 To inject an environment variable, add a new property to the container called envFrom. The envFrom 54 00:04:33,710 --> 00:04:41,210 property is a list so we can pass as many environment variables as required each item in the list corresponds 55 00:04:41,210 --> 00:04:42,950 to a secret item. 56 00:04:42,950 --> 00:04:46,190 Specify the name of the secret we created earlier. 57 00:04:46,190 --> 00:04:52,610 Creating the pod definition file now makes the data in the secret available as environment variables 58 00:04:52,760 --> 00:04:54,670 for the application. 59 00:04:54,680 --> 00:04:59,260 What we just saw was injecting secrets as environment variables into the PODs. 60 00:05:00,450 --> 00:05:04,100 There are other ways to inject secret into PODs. 61 00:05:04,250 --> 00:05:11,290 You can inject as single environment variables or inject the whole secret as files in a volume if you 62 00:05:11,290 --> 00:05:14,370 were to mount the secret as a volume in the pod. 63 00:05:14,410 --> 00:05:21,130 Each attribute in the secret is created as a file with the value of the secret as its content. 64 00:05:21,130 --> 00:05:27,340 In this case since we have three attributes in our secret three files are created and if we look at 65 00:05:27,340 --> 00:05:31,930 the contents of the D.B. password file we see the password in it. 66 00:05:32,300 --> 00:05:33,860 That's it for this lecture. 67 00:05:33,880 --> 00:05:38,140 Head over to the coding exercises and practice working with secrets.