Welcome to part 2 of the session on OCI identity and access management level 200.

My name is KD. And I am a part of the OCI product management team. In the first
part of this session, we summarized the Identity and Access Management or the IAM
service and its key components. And then we went deeper into what instance
principals are, why they are useful, and how do you configure dynamic groups to use
Instance Principals.

We will start part two with multi-factor authentication and how do you set it up in
OCI. And then we will look at how do you write IAM policies in a more advanced
manner.

I'm going to skip the first few slides since they were covered in part one. We will
start part two with multi-factor authentication. I think pretty much everyone who's
listening or watching this video is familiar with MFAs. But the notion of multiple
factor indication is that it requires you to use more than one way to authenticate
your identity.

In general, the MFA may include two of the following components, something you
know, like a password, and something you have, like a device, with a MFA app in it
that generates a code. And then another option is something that you are for like
your fingerprint. So in this case, by using MFA multifactorial indication in OCI,
you would need your username/password as the first factor of authentication.

And the second factor of the authentication is using a MFA app to generate the one
time temporary password that you would need as the second factor. And once you are
able to provide these two forms of authentication, you are then logged in.

So multi-factor authentication is a best practice from security point of view. MFA

is enabled for a specific user and for a specific device that this user has. The
procedure to enable MFA for a user includes the registration of this mobile device
and the mobile authenticator app on it.

The two apps that we have tested this against and that are supported are the Oracle
Mobile Authenticator app as well as the Google Authenticator app. You can get these
apps from the app store in your device ecosystem, the Google Play Store, or the
Apple Store for iPhones.

And let's actually take a quick look at how do you set it up in the OCI console. So
in this case, I am on my user details page. You will click on Enable Multi-Factor
Authentication.

When you click that, you will be presented with a code. And this QR code you have
to scan with the device using the authenticator app. And then you would be
presented a code. And that verification code is put over here. And once it has set
it up, the next time you want to log m besides your password, you will be asked for
this one time, temporary password.

All right. So the next thing I want to talk about is IAM policies and dive deeper
into how you can write very granular policies with IAM in OCI. So the policy
syntax, if you have seen the part 100, this should look familiar to you. If you
have not seen it, I would encourage you to please watch that series first, because
they will go into IAM policy basics in a deeper manner but I'll summarize here.

You know, the policy syntax starts with allow. And you can put more than one space
or you can break up the line. Does not matter. But after allow, you put a subject.
The subject could be one or more than one comma [INAUDIBLE] groups that you have
set up in IAM.

These groups can be listed by name or by their OSIC. So you can put groups, you can
put dynamic groups, or you can also say any-user. If you say any-user, it would
apply to all the users.

So again, you can have the names that are separated by comma or you can have the
keyword group or dynamic group followed by the keyword ID. And then the OSIC. Then
you can have comma. You can have another idea and then the OSIC, et cetera.

So after you have put in the right subject or subjects, you specify the verb that
you want to use based on the type of access. The four verbs are inspect, read, use,
and manage. Inspect gives you ability to just list the resources. And manage
includes all the possible permissions and read and use, in between inspect and
manage. After the verb, there you can only put one verb in one policy statement.
You can have multiple statements in a single policy document, but for each
statement, you can only put one verb.

You then specify a resource type. This resource type could be a single resource
type. And you know this could be individual resource, or there could be a family
resource type. A single resource type, you can include individual resources. You
can say things like VCN or subnet or objects. These are all examples of individual
resources.

You can also write a family of resource type. The families are listed here. These
families sort of-- club of an idea for related components together. And, for
example, the object family would include the resource types of buckets and objects.
But if you want to write a policy against object family, both these types of
resources are included. This just makes it easier to write policies on unrelated
type of resources.

And then there is a location. You must specify a location. You can specify a single
compartment or the batch name of that compartment or its closet, or you can just
say a tenancy to cover the entire tenancy. You have to put some location in there.

If you want to attach a policy to a compartment, you must be in the compartment

when you create the policy. And, finally, there is an optional where and then
conditions. And these where conditions are the more advanced form of writing
policies. We will look at some examples of what kind of conditions that you can put
in your IAM policies next.

Let's first look at an example policy before we go into verbs and permissions. I
have my-- I've logged into my OCI console. So you can get into policies through
identity, and the policies, they apply at the compartment level, or you can also
apply policies at the root compartment level as well.

So to create a policy, an example policy, let me first create a new group. I will
not add users to the group, but let me create a group called Network Admins. Admins
for network resources in their tenancy. So this group is going to be my network
admins for all the VCN subnet and internet gateways, DLGs, all of that. So all of
that is part of the virtual network family, so I don't have to specify all these
resources separately.

So I'm at the root level because I want to write to tenancy level policy. I can
call it Policy. And the statement could be something like "allow group network
admins to manage virtual network family in their tenancy." So rather than
specifying everything separately in terms of which resources to manage, I just keep
the single name.

What I can also do is, as I was saying earlier, instead of the group name, I can
also specify the group ID right here. So I can say something like, go to the
statement, and I can-- let me just add a new statement. "Allow group ID," and then
this will set to "Manage network, virtual network family in tenancy." So I can add
statements like this.

Now, let's discuss the notion of permissions. Permissions, if we define it, it's
just a atomic unit of authorization that is given to a user via a group when you
write the policy. And this permission enables this user to perform operations on
the resources. So this is the authorization mechanism. So all the permissions are
defined in the policy language.

So when you actually write a policy in which you give group access to a particular
resource or resource family using a verb, what essentially happens is you're giving
permissions, some predefined permissions for certain API operations. So to make it
easy, let's read this diagram on the right. The best way to read this diagram is,
when you, let's say, write a policy, vetoed the policy called allow group network
admins to manage the virtual network family and tenancy.

So in this case, your verb in this example is "manage," so when you write the
policy with the "manage" verb and the resource is actually the volumes family, in
this case, what you end up essentially doing is giving up some permissions, some
predefined permissions. These permissions include a volume delete, volume create,
and all the permissions given by the use verb. A use verb gives it volume right,
volume update, and all the permissions given by read, which gives it a volume
inspect permissions.

So, essentially, writing a policy called Allow group name, any name, to manage
volumes valid family in tenancy would give this group the permissions to delete
volumes, create volumes, write volumes, update volumes, and inspect volumes in the
tenancy. And what these permissions actually translate to is allowing certain API
operations. So once you have the volume delete permissions, you will be able to do
the delete volume API operation under these sources.

And if you have the volume create permissions, you'll be able to do the "create
volume" API operation. Certain permissions give access to more than one API
operations. So in this case, volume and spec gives "get volume" and "list volume"
API operation authorization to your end user.

So what the verbs are essentially helping you is to, rather than remember all these
permissions, rather than writing all the permission names for all the resources,
you now just have to remember the verbs and just a combination of verb, and the
resource type is going to give you all the permissions you need for the API
operation. Just makes it easier for you.

For example, if you want to take a look at the policy language and look at all the
permissions, permissions are essentially what comes out of work plus resource-type
combination. This is the policy reference. You can go to the documentation and get
to it. You will see that even for something like a subnet, there are a whole bunch
of permissions. All these permissions are covered by the "manage" verb, this plus
everything in the use is covered by a single verb, "manage."

So rather than giving all these permissions, which allow all these APIs to happen,
rather than listing them explicitly, the verbs just make it very easy for you to
intuitively write very powerful policies in an easy manner. I know that's a big
differentiator with OCI. And another thing is, for certain API operations, you
would need multiple permissions as well.

Let's say that you want to allow a user to be able to attach some volumes to an
instance. You must need access to multiple permissions in this case. In this
example, you see that a single permission is giving access to multiple operations,
but sometimes for a single operation, you might need access to multiple
permissions. For the attach volume, you would need access to permissions called
volume right. So volume right is somewhere here.

So you would need access to this permission, but you would also need to get access
to the volume attachment, create and volume instance and the instance attach volume
permissions, so three different permissions required for a single API operation.
Some of these permissions are part of the volumes value family, and some are part
of the instance family. So for certain API operations, you might need to write more
than one policy as well.

And the commonly used policies are actually provided in the documentation as well,
so if you go through documentation, you can go to the policy reference, like I
showed, but you can also go to Common Policies. And we will give you examples of
all the commonly used policies. So it's a good starting point for you as you are
getting started with writing IAM policies and getting into advanced features of
writing policies in OCI.

This would tell you, for example, to give [INAUDIBLE] inspect permissions. In your
[INAUDIBLE] resources, you would need to write these three policies. know It's a
good resource for you to get started with OCI policies.

All right, so now let's get into the details of the where conditions, the condition
itself. So after the where keyword, you need to specify a condition. The condition
itself has two parts, so it has a variable and a value. So you write "variable is
equal to value" or "variable is not equal to value." And the variables are of two
types themselves. There are the request kind of variables, and then there are
target kind of variables. The request kind of variables have something to do with
the API operation being requested, and the target kind of variables are something
related to the resources on which the policy is going to act.

So you either write "request dot something," or you write "target dot something."
So the request variables could be request.operation. So this is an API operation-
type of variable, and this is request.permission. The request.user.ID or set of the
requesting user. So this is all related to the requests that also of the groups is
request.groups.ID. And there is request.region in this example. There is allow
groups-- a group called Phoenix Admins to manage all resources in the tenancy,
where the request.region is this phx.

And this would actually-- when you evaluate this condition, it's either going to be
true or false. If it is true, the policy is enforced is valid. And if it is false,
the policy is not enforced. The policy does not apply for that particular request
in this case. And when it comes to the value part, there can be two type of values.
There could be a single string kind of value or a pattern kind of a value. The
string value is a single thing, and single quotation mark around that, like the phx
we saw on the last slide.

And then there is the pattern kind of values, in which you can do a pattern
matching, far more complicated kind of scenario. So in this case, HR* matches the
string that starts with HR. And it's the normal pattern-matching kind of syntax. So
where the condition has values, variables, which are the request dot something or
target dot something and then the value can be in single quotation mark or it could
be a pattern-matching kind of value, you can specify one or more than one
conditions.

The single condition we already looked at. This, for example, is a single
condition. You write "where," and then there is the variable and then the value.
This is a single condition, but after "where," if you put "any" or "all," then you
can have multiple pairs of variables and values in it.
In this example, you allow this group XYZ to manage groups and tendency where any
request or completion is all of this. So "if any," so this is "all" kind of an
operator. And in this other example, where the keyword is "all," this is "and" kind
of operator, so both these conditions need to be true for this thing to be valid.

So as you can see, using the where conditions, you can be very dynamic in your
policies. So these are evaluated when they're enforced, and the conditions are
evaluated, and if the condition is true, then it's enforced. And you can write
"and" and "all" kind of conditions for multiple conditions in a single policy
statement. And you can have values which are string or pattern type to match a lot
of different options at the same time.

This is an example of some advanced policies. Actually, let's go back to the

console and continue working on the advanced policy using the policy we were
looking at. So we had these two policies for our network admins. So let me just
delete these. Hold on.

I will also need-- actually, I need to, for my policy, I am going to target a
particular compartment. So let me get that compartment ID. Let's see that. I want
to write this policy on the compartment called "IT." So I can now write a policy
that says something like "allow group network admins to manage virtual network
family."

Now, I put "where" instead of, in tenancy, I just put "where." Target are
"compartment.ID equals," and then I can put the other-- I forgot the location. I
still need to specify where before we have the location, and then I can now
complete my statement.

Now, this statement is applied, so you can look at some more examples quickly. The
first example is for a group called Group Admins to manage groups in the tenancy
where the target.group.name is the pattern matching of a-users-something. So all
those groups with this pattern would be where this policy is applicable.

The second example shows allow the group admins to manage the membership of any
groups besides the administrators group. So in this case, the target.group.name
variable and the value is "not equal to administrators" or "anything except
administrator" would be true for this particular condition. And then you can write
even more finer-grained policies than that using the "all" and "kind of" keywords
like we looked at.

And the last example is, in this case, there is a group called Training Group that
needs to manage the virtual network family, so VCNs et cetera. And the location of
this policy is in the compartment called Training. They are allowed to manage
everything related to network, virtual family, except where the permission is
request or permission is recently leaked. So they cannot delete the VCNs, and other
than deleting the VCNs, anything else related to the networks they are able to do
that.

With that, let me wrap up this part. In this part, we looked at some of the
advanced policy features, and we discussed the concept of verbs and permissions and
how they give access to API operations. We looked at the "where" conditions and
what kind of conditions you can write and what the two type of variables are, the
request and the target variables. The two types of values could be a string kind of
a value or a pattern-matching kind of a value.

And then we have "any" or "all" keywords for writing multiple conditions in a
single where with a single "where" keyword.

Thank you for your time, and I look forward to having you join in the next part of
this session.