Let's set up our tenancy for using API gateway. API gateway is a network attached device. If we do not yet have a virtual network, we need to first create one. The virtual Cloud network, or VCN, contains multiple resources. For example, subnets. Our subnets can be both public and private. API gateway appears as a network device on the subnet of your choosing. API gateway is fully managed by Oracle, and then it has built-in failover capabilities. Therefore, when creating a gateway, you will always use a regional subnet. When you create a gateway, the API gateway service automatically provisions your gateway with an active and failover instance. The region with multiple availability domains, the instances are created in separate availability domains. If there is ever an interruption to the service and the availability domain the act of instance is running in, the service will automatically fail over to the backup domain. In the case of a single AD region, the gateway will be provisioned across two fault domains. All of this is transparent to the user. As you set up your network, you will need to ensure that the traffic and ingress into and egress from the gateway. Oracle Cloud infrastructure is secure by design and follows the principle of least privilege. This means that the appropriate ingress rules need to be added to the security lists. Depending on your chosen network topology, you may need to add appropriate routes to your route tables. Continuing the principle of least privilege, access is never assumed and policies have to be added to explicitly allow access. It is best practice to set up a well-defined groups in OCI identity management and then add the appropriate policies for the access needed. Users are not directly granted access to resources, rather policies are created to grant access to groups and users are then added to those groups. When a new user is created, that user has no resource access until that user is assigned to a group. When enabling your teams to develop APIs, they will need to be granted the appropriate permissions through group membership. Resource to resource access is also controlled through policies. For example, if you want to create a serverless API with API gateway and functions, you must add a policy to allow API gateway to invoke the function. Here we are in the OCI console. As we talked about before, we need to set up the network and also security policies before we use our first API gateway. The first thing we want to do is go ahead and create a network. I'll go ahead and go into networking and I will select virtual Cloud networks. Super important is to make sure that you have the appropriate compartment. Here I have L100 development check, and that's what I want. I'm going to go ahead and create a virtual Cloud network. Now what I can do is I can create a VCN or I can start the VCN wizard. Here I'll get my VCN a name. Again, I'm ensuring that I am in the appropriate development compartment, L100 development. My cider blocks are automatically filled out for me. I'll go ahead and leave those as is. Everything looks good. I'm going to go ahead and create my VCN. The wizard will go through and create all the necessary resources for my VCN fairly quick. My new VCN is created. Let's go ahead and view it. In my VCN, I have a number of resources. I have a private subnet and a public subnet. API gateway can work on either private or public subnets for different use cases. I also have a number of other resources created, such as my NAT gateway, my service gateway, DHCP options, my security list. As a matter of fact, security lists are super important. This is something that will trip a new user up for API gateway. The example is I go and create my VCN and then I'll ultimately create my gateway, create an API and I'll want to test it. As I go to invoke it from my test client, from the Internet, I will be confused and that I won't be able to get a response. My gateway will appear to me that it is not working. What it is is the security list has not been properly configured. In this case, what I'm going to do is I'm going to go to my default security list for the L100 API management, DCM, and I'm going to add an ingress rule. Notice here there's a default ingress rule of port 22, which is SSH. That's all you get when you set up a network. OCI is secure by design, so there's no assumptions made as to what type of resources you're going to run, and all of your security lists are totally locked down and you have to actively open up the appropriate ports. I'm going to add an ingress rule. What I'm going to do is I'm going to say 0.0.0.0/0, essentially everything from the Internet. The IP protocol is TCP and I'm just going to say 443. API gateway only allows HTTPS traffic and at this point, so what I'll say is HTTPS traffic for API gateway. This is an optional description. But just as I go back, and I'm looking at this at a later point and if I'm wondering why I have that open, I have a description telling me why. Super important step, like I said, a lot of people what happens is that, they get into trying things out, then up the gateway, wondering why they can't connect to it. Simple thing, we just need to go ahead and allow open the gate, so to speak to allow that traffic to come in to API gateway. As far as networking is concerned, we're all set. Let's go ahead and create some policies. I'm going to go to identity and security, and I'm going to select policies. Here I'll create a policy. I give my policy a name. Well, API gateway call functions. This is my development compartment. I'm going to go ahead and select the manual editor. This is a little more complex policy, but once we go through it, it'll make sense. I have this already copied just for time, and I'll go ahead and paste this in. What does this tell us? We're going to allow any user to use functions family in the compartment development where these are conditions, all the request's principal type is API gateway and request resource compartment ID is this compartment ID. This is the compartment development compartment ID. My Gateway will happen to be in the same compartment as my functions, but I can have those in separate. I could have a policy that is defining for functions in a separate compartment altogether, different users are working on those, and I need to allow the gateway to be able to invoke those functions at runtime. This is for creating server-less APIs, and so we want to give API Gateway the resource principle access to be able to invoke functions. That policy is created. I could add a few more policies, and I'm going to go into another compartment just to show those examples. If I look in this compartment, I have a set of policies for my API developers. I've set up a number of groups of API developers, API managers, gateway managers and so forth. My API developers can manage the API gateway, they can manage the network, the functions, everything within the development gateway, development compartment rather they can work. They're free to do what they need to do to build their APIs. Just for context and a little bit of an example. Let's go ahead and take a look at the QA compartment. Here I have access control for developers and testers QA UAT. When I take a look at this, I can see that I have a group API testers, and they can manage the API gateway and the QA compartment functions family, they can work with that. If we look down the line, we can see developers can view those resources, but they can't change the resources. That's as the API progresses through the development life cycle, we do not want developers making changes directly in QA. We would want to limit that. We have a testers group. This is how we give rights to users to be able to work at development time and configuration time. We add those users to groups. We assign the rights to the groups, and then we go ahead and create the appropriate policies to allow the appropriate access. But again, at runtime, that policy I created for the gateway is a dynamic policy, because any gateway I create in that compartment would have access so I can add and change and take away gateways. I don't have to add each one into a specific group to solve that. That covers what we need for networking and also policy. Let's go ahead and go create a gateway. I'm going to go back to my menu. I'm going to select developer services. Under API Management, I'm going to select gateways. I'm going to ensure that I'm in the correct compartment. I'm going to select L100 in development. Now go ahead and create a gateway. Give my gateway a name. This one I'll make a public gateway. You can make a public or private gateway. This one I'll make public because I want to have a publicly accessible address, so I can create APIs in test against it. It's in the correct compartment L100 development. I'm going to go ahead and select my ECN that I created, which is my L100 API management. You notice we have regional subnets here, private and public. I'm going to go ahead and select public. Then I'll go ahead and create my gateway. My gateway has now been created, and I'm ready to go, just start creating APIs and deploying them.
