# Quick Start

<!--- Template Guidance 
Write a short introduction and the getting started guide to your product. 
If there are any standout features to call it, this is probably the place to do it. 

NOTE: Take a look at the quick-start of Object Storage (community/community/content/product/storage/object-storage/quick-start/_index.md) for an idea on the tone and the level of detail. 
-->

This is a quick start guide focusing on the creation of new API Keys and Roles. 
For more in-depth knowledge of IAM, please refer to the
[Policy Guide]({{< ref "/product/security/iam/how-to/policy-guide/" >}}) and the


## Prerequisites 
The goal is to have the necessary resources to use IAM outside of the portal too.

1. Navigate to IAM, then ROLES, and add a new Role.
2. In the Role creation form: name your new Role `example-api-role` and leave other settings as default - make sure "Default service strategy" is _ALLOW_ and "Service Classes" is empty. This will create a role with no restrictions.
3. Navigate to IAM, then KEYS, and add a new API Key.
4. In the Key creation form: name your key `example-api-key` and select the Role from the previous step (`example-api-role`).
5. Once created, the API key id `API Key` and secret `API Secret` are displayed. The secret is displayed only once. We will need both for the next step.
6. This documentation shows you 
[how to configure the CLI with the API key you just created]({{< ref "/tools/command-line-interface/#configuration" >}}). If you haven't installed the CLI yet, you can [refer to the Installation section]({{< ref "/tools/command-line-interface/#installation" >}})


##  Roles and API Keys 
You can create a Role and API keys from the Portal or the [CLI]({{< ref "/tools/command-line-interface/" >}}).
Every role defines a policy in charge of authorization. API keys are attached to a role, they are responsible for authentication.


###  From the CLI
#### Creating a new API key

```bash
exo iam api-key create second-api-key example-api-role
```

Because we specified the same role from the first time setup, this will create another key with **unrestricted** use of all API operations - identical to the one we created previously.

For most use cases however, we recommend that you create a **restricted** Role that can only be used for certain operations. 

#### Creating a new Role

```bash
cat policy.json | exo iam role create example-restricted-role --editable --policy -
```

`policy.json` defines the role's policy. 

For example, here's a policy that allows IAM operations, allows DNS operations, but denies anything else:

```json
{
  "default-service-strategy": "deny",
  "services": {
    "dns": {
      "type": "allow"
    },
    "iam": {
      "type": "allow"
    }
  }
}
```

`"default-service-strategy": "deny"` rejects any request that doesn't satisfy the conditions under `"services"`.

`"services"` are high level classification of operations used to split the authorization flow. Possible keys inside `"services"` are: `compute`, `iam`, `dns`, `dbaas`, `sos`, `block-storage`, `ai` and `organization`.

You can find more information about which operations/endpoint belong to which service and more details of command-line usage for IAM in the following references:

- [API-IAM reference](/reference/api/iam/)
- [CLI-IAM reference](/reference/cli/exo/iam/)