Welcome back. Before you can actually do anything in the OCI CLI, you'll have to set up authentication that let's OCI know who you are. So in this video, we'll go over the different methods of CLI authentication. Recall that all interaction with OCI is through a rest endpoint and that all the CLI does is generate and sends requests to that endpoint. But before the endpoint passes that request onto any other service, it asks the identity and Access Management Service to verify that you are who you say you are, also known as authentication, and that you are allowed to perform the action that you're requesting, also known as authorization. To facilitate this, your CLI client attaches some sort of identification to its API requests. Just to get a little more concrete in the API call example we showed earlier for creating a VCN and that just means adding some headers right here. That function like a username and password. But again, knowing the details of the API isn't that important. In any case, the two types of identification that we'll be going over are API keys and security tokens. API keys are the easier but less secure method. To use one you generated in OCI usually through the console, download it onto your machine and then pointer CLI to it. Then your CLI can attach it to all of the API requests it makes. There are two main reasons it's not particularly secure. First, the key does not automatically expire. It's valid until you specifically deactivate it with OCI. Second, the key isn't bound to any particular machine so any machine that has the key can authenticate with it. What API keys are nice for use cases that don't require tight security, we generally recommend the other method, security tokens. To use a security token, you first tell your CLI that you want to use one. Then, it sends a request to OCI, which in turn redirects you to a browser where you can sign in. Then OCI gives your machine a session-based token that automatically expires after an hour unless refreshed. During this session, your CLI can attach the token to your API requests, authenticating as you. While you do have to sign in every time that you sit down to use the CLI, security tokens are much more secure than API tokens. So far, we've talked about using the CLI from local machines. But you can also use the CLI from machines within OCI, like compute instances and functions. Because these machines have OCI-managed metadata, like OCIDs. Instead of authenticating as you, they can just attach their own identities. For compute instances, this is called instance principle authentication and for functions, it's called resource principle authentication. Of course, just authentication isn't enough so there have to be policies within OCI that authorize these principles. But we'll talk about that in a later module. The last thing I'll mention is the Cloud Shell. The Cloud Shell is a web application within the Cloud console that's streamlined CLI usage. It works by automatically provisioning a small compute instance with pre-configured security tokens and connects to it through your browser. Then the CLI Client itself runs from the compute instance so it can attach its security tokens to your API requests. For the most part, this is where we will be doing all of our CLI work, and that's it. We have that the two basic ways of authenticating from the CLI are API keys and security tokens. Machines within OCI can use their metadata, for instance, principal and resource principle authentication and finally, the Cloud Shell is a mini app within the Cloud console that connects you to an OCI-managed VM with pre-configured security tokens. Next up, we'll take a look at some of these in action and then begin discussing the basic syntax of CLI commands. See you there.
