Morio Settings: iam

The iam settings control identity and access management in Morio. Specifically, they allow you to configure identity providers and control how they are displayed in the UI.

info

The iam settings only apply to HTTP-based access to Morio. Access to Morio’s Kafka API is always authenticated by .

iam.providers

Optional The iam.providers key holds one or more identity providers that are enabled on your Morio deployment.

This key holds and object where the properties of the object are the id of the different identity providers. There are two two types:

• An identity provider that only can be instantiated once will have a predefined key. The apikey and local IDPs fall into this category.
• An identity provider that can be instantiated more than once will have a key that can be freely chosen and will serve as the IDP’s id. The ldap IDP falls into this category.

The Morio root token just works

The Morio root token provider (mrt) is enabled by default and does not require configuration. In other words, authenticating with the Morio root token just works, even if not providers are set up.

You can configure the inclusion or appearance of the mrt provider on the UI’s login page through the iam.ui settings, or disable it altogether with the DISABLE_IDP_MRT feature flag.

Optional This configures the apikey identity provider.

iam.providers.apikey.provider

Mandatory To enable the apikey identity provider, this must be set to apikey.

iam:
  providers:
    apikey:
      provider: apikey

iam.providers.apikey.label

Optional This is a label that will be shown to the user in the UI Service.

iam:
  providers:
    apikey:
      label: API Key

iam.providers.apikey.about

Optional This is a description that will be shown to the user in the UI Service.

iam:
  providers:
    apikey:
      about: This allows you to test your Morio API Key

iam.providers.local

Optional This configures the local identity provider.

iam.providers.local.provider

Mandatory To enable the local identity provider, this must be set to local.

iam:
  providers:
    local:
      provider: local

iam.providers.local.label

Optional This is a label that will be shown to the user in the UI Service.

iam:
  providers:
    local:
      label: Morio Account

iam.providers.local.about

Optional This is a description that will be shown to the user in the UI Service.

iam:
  providers:
    local:
      about: Log in with your Morio account

iam.providers[id]

This creates and additional identity provider with a chosen id. This allows you to set up multiple identity providers of this type.

iam.providers.[ldap-id]

Optional This configures an ldap identity provider.

info

We use [ldap-id] as a placeholder here. This is a freely chosen id, and we will use ad in our examples because using this to authenticate against Active Directory is a common use-case.

iam.providers.[ldap-id].provider

Mandatory To enable an ldap identity provider, this must be set to ldap.

iam:
  providers:
    ad:
      provider: ldap

iam.providers.[ldap-id].label

Optional This is a label that will be shown to the user in the UI Service.

iam:
  providers:
    ad:
      label: AD Account

iam.providers.[ldap-id].about

Optional This is a description that will be shown to the user in the UI Service.

iam:
  providers:
    ad:
      about: This is your Active Directory account, the same you use to login to your computer.

iam.providers.[ldap-id].username_field

Mandatory This sets the LDAP field that shall be used as the username.

iam:
  providers:
    ad:
      username_field: samaccountname

iam.providers.[ldap-id].trust_certificate

Optional Set this to a PEM-encoded certificate that should be trusted when connecting to the LDAP server over TLS.

iam:
  providers:
    ad:
      trust_certificate: | -
        -----BEGIN CERTIFICATE-----
        MIIDfjCCAwSgAwIBAgISAxT9oF2eiPOpmGj6Imea6R41MAoGCCqGSM49BAMDMDIx
        CzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJF
        NjAeFw0yNDA3MTcwNDAyMTNaFw0yNDEwMTUwNDAyMTJaMBMxETAPBgNVBAMTCG1v
        cmlvLml0MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAERficTiGhJRS5Pso7hOpM
        i2WLILmC3AdE/ztGs0XCIrHs7sSsj0shApL1G9/+bXTNuuB+LmbF3vLR92R8qrhT
        z6OCAhcwggITMA4GA1UdDwEB/wQEAwIHgDAdBgNVHSUEFjAUBggrBgEFBQcDAQYI
        KwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUMYu6mooQXgJ6RvxaAahr
        M0GIhFgwHwYDVR0jBBgwFoAUkydGmAOpUWiOmNbEQkjbI79YlNIwVQYIKwYBBQUH
        AQEESTBHMCEGCCsGAQUFBzABhhVodHRwOi8vZTYuby5sZW5jci5vcmcwIgYIKwYB
        BQUHMAKGFmh0dHA6Ly9lNi5pLmxlbmNyLm9yZy8wIQYDVR0RBBowGIIIbW9yaW8u
        aXSCDHd3dy5tb3Jpby5pdDATBgNVHSAEDDAKMAgGBmeBDAECATCCAQMGCisGAQQB
        1nkCBAIEgfQEgfEA7wB1AD8XS0/XIkdYlB1lHIS+DRLtkDd/H4Vq68G/KIXs+GRu
        AAABkL8RzlUAAAQDAEYwRAIgc1iJUySn/2LPWmmlM41XTtBHIxRf1ko90PEt+tSd
        fJMCIH1SXpmOh6NR4nPuqUAlXp5/9ktjH8F2E0yiqXGjYMhaAHYAdv+IPwq2+5VR
        wmHM9Ye6NLSkzbsp3GhCCp/mZ0xaOnQAAAGQvxHOiwAABAMARzBFAiACLbgSLlbv
        RAi36rsJsmtMHrxw9/G+uIT7OtP/zaG3CAIhAKtsVad4/fIdHTLAk4GtAxkaKj+a
        l2tL6EXSgHRMbrptMAoGCCqGSM49BAMDA2gAMGUCMDEpM51fn4T/GUI6LVvA0LRr
        b/DPCwXecIjIb43DO24pod5qKF+fL2xNr/wnaMxHKgIxAO7TTelusI229SmOkQFq
        sbupQw74yW6UK64tYLxu8sfRbx60OfpNtmIyDd9poHpSzQ==
        -----END CERTIFICATE-----

iam.providers.[ldap-id].verify_certificate

Optional Set this to false to skip verification of the LDAP server’s TLS certificate.

tip

Rather than disable verification, set the trust_certificate setting instead.

Default

iam:
  providers:
    ad:
      verify_certificate: true

Disable certificate verification

iam:
  providers:
    ad:
      verify_certificate: false

iam.providers.[ldap-id].server

Mandatory This sets the LDAP server that will act as the authentication backend.

It requires settings to:

• Find the server: the url setting
• Do the initial bind: the bindDN and bindCredentials settings
• Search for the user who is trying to authenticate: the searchBase and searchFilter settings

iam.providers.[ldap-id].server.url

Mandatory Set this to the URL that will be used to connect to the LDAP server, including the protocol.

iam:
  providers:
    ad:
      server:
        url: "ldaps://dc1.tokyo.morio.it

tip

While both ldap:// and ldaps:// are supported, you should really only use ldaps:// for in production.

iam.providers.[ldap-id].server.bindDN

Mandatory Set this to the distinguished name (DN) that should be used to bind to the LDAP server.

iam:
  providers:
    ad:
      server:
        bindDN: "CN=morio-ldap,OU=Users,DC=tokyo,DC=morio,DC=it",

info

LDAP servers typically do not allow an anonymous search. So we need to bind to the LDAP server to be able to find the user. This bindDN is the LDAP-equivalent of the username used for that initial bind. You should probably create a dedicated service account for this that does not have any privileges apart from looking up information.

iam.providers.[ldap-id].server.bindCredentials

Mandatory Set this to the distinguished name (DN) that should be used to bind to the LDAP server.

Using inline credentials

iam:
  providers:
    ad:
      server:
        bindCredentials: 'this is not a good idea, use a secret or vault instead'

Using a secret reference

iam:
  providers:
    ad:
      server:
        bindCredentials: '{{ MORIO_AD_BIND_PASSWORD }}'

Using a vault reference

iam:
  providers:
    ad:
      server:
        bindCredentials:
          vault: 'morio/prod:MORIO_AD_BIND_PASSWORD'

iam.providers.[ldap-id].server.searchBase

Mandatory Set this to the location in your LDAP structure where we should search for user accounts.

iam:
  providers:
    ad:
      server:
        bindCredentials: "{{{ AD_PASSWORD }}}",
        searchBase: "OU=Users-EU,DC=tokyo,DC=morio,DC=it",

iam.providers.[ldap-id].server.searchFilter

Mandatory Set this to an LDAP filter to further limit the scope of the search for matching user accounts.

iam:
  providers:
    ad:
      server:
        bindCredentials: "{{{ AD_PASSWORD }}}",
        searchFilter: "(&(objectClass=user)(samaccountname={{username}}))"

iam.providers.[ldap-id].rbac

Mandatory This controls role assignment to user accounts backed by an LDAP identity provider.

iam.providers.[ldap-id].rbac.[role]

Optional There are 4 different roles that can be assigned: user, manager, operator, and engineer. They govern Morio-specific permissions, with engineer having the highest and user the lowest access.

For each role, you can specify the attribute to match against, and either a regular expression with the regex key, or an explicit list with the list key. When the expression matches the attribute value, or it is included in the list, that role will be assigned to the user.

info

We will use the user role in our examples below.

iam.providers.[ldap-id].rbac.[role].attribute

Mandatory This defines the attribute to match against to determine whether or not to assign the role.

iam:
  providers:
    ad:
      rbac:
        user:
          attribute: samaccountname

iam.providers.[ldap-id].rbac.[role].list

Optional This defines a list (an array) of values. If the attribute value is in the list, the role will be assigned.

iam:
  providers:
    ad:
      rbac:
        user:
          list:
            - mario
            - luigi

tip

For higher-order roles, like operator or engineer, we recommend defining an explicit list, rather than using a regular expression. This makes it easier to see who has elevated access, as well as avoid issues with regular expressions matching broader than intended.

iam.providers.[ldap-id].rbac.[role].regex

Optional This defines the attribute to match against to determine whether or not to assign the role.

iam:
  providers:
    ad:
      rbac:
        user:
          regex: .

info

In the example above, the regex . matches anything. So every user who can successfully authenticate to LDAP will get the user role.

iam.providers.[oidc-id]

Optional This configures an oidc identity provider.

info

We use [oidc-id] as a placeholder here. This is a freely chosen id, and we will use gitlab in our examples showing how to use GitLab as an OpenID Connect provider.

iam.providers.[oidc-id].provider

Mandatory To enable an oidc identity provider, this must be set to oidc.

iam:
  providers:
    gitlab:
      provider: oidc

iam.providers.[oidc-id].label

Optional This is a label that will be shown to the user in the UI Service.

iam:
  providers:
    gitlab:
      label: GitLab Account

iam.providers.[oidc-id].about

Optional This is a description that will be shown to the user in the UI Service.

iam:
  providers:
    gitlab:
      about: This will redirect you to GitLab for authentication.

iam.providers.[oidc-id].username_field

Mandatory This sets the user property (field) provided by the OpenID provider that shall be used as the username.

iam:
  providers:
    gitlab:
      username_field: preferred_username

iam.providers.[oidc-id].issuer

Mandatory This is the base URL of the OpenID provider (or issuer). It is typically sufficient to configure this, and not provide an autodiscovery_url.

iam:
  providers:
    gitlab:
      issuer: "https://gitlab.morio.it"

iam.providers.[oidc-id].autodiscovery_url

Optional Configure this if your OpenID provider does not use the default auto discovery URL. This is typically the case for OpenID providers that support multi-tenancy, such as Keycloak or Microsoft Entra ID.

iam:
  providers:
    gitlab:
      autodiscovery_url: "https://gitlab.morio.it/.well-known/openid-configuration"

iam.providers.[oidc-id].client_id

Mandatory The client ID (sometimes called application ID) as configured in the OpenID provider.

iam:
  providers:
    gitlab:
      client_id: 9f8afda548c112e70323ff60ff3d080b3216c691a05e69ca8b08e146085adf27

iam.providers.[oidc-id].client_secret

Mandatory The client secret (sometimes called application secret) as configured in the OpenID provider.

iam:
  providers:
    gitlab:
      client_secret: "{{{ GITLAB_OIDC_SECRET }}}"
secrets:
  GITLAB_OIDC_SECRET: "Your client secret here"

iam.providers.[oidc-id].rbac

Mandatory This controls role assignment to user accounts backed by an OpenID Connect identity provider.

iam.providers.[oidc-id].rbac.[role]

Optional There are 4 different roles that can be assigned: user, manager, operator, and engineer. They govern Morio-specific permissions, with engineer having the highest and user the lowest access.

For each role, you can specify the attribute to match against, and either a regular expression with the regex key, or an explicit list with the list key. When the expression matches the attribute value, or it is included in the list, that role will be assigned to the user.

info

We will use the user role in our examples below.

iam.providers.[oidc-id].rbac.[role].attribute

Mandatory This defines the attribute to match against to determine whether or not to assign the role.

iam:
  providers:
    gitlab:
      rbac:
        user:
          attribute: preferred_username

iam.providers.[oidc-id].rbac.[role].list

Optional This defines a list (an array) of values. If the attribute value is in the list, the role will be assigned.

iam:
  providers:
    ad:
      gitlab:
        user:
          list:
            - mario
            - luigi

tip

For higher-order roles, like operator or engineer, we recommend defining an explicit list, rather than using a regular expression. This makes it easier to see who has elevated access, as well as avoid issues with regular expressions matching broader than intended.

iam.providers.[oidc-id].rbac.[role].regex

Optional This defines the attribute to match against to determine whether or not to assign the role.

iam:
  providers:
    gitlab:
      rbac:
        user:
          regex: .

info

In the example above, the regex . matches anything. So every user who can successfully authenticate to the OpenID provider will get the user role.

iam.ui

Optional insofar as the entire UI Service is optional.

The iam.ui key holds details on how various identity providers should be integrated in the UI Service that provides web-based user interface.

iam.ui.visibility

Mandatory for each identity provider id this controls the visibility on the login screen.

iam.ui.visibility.[provider-id]

Mandatory Set this to icon to hide the provider behind an icon. Set it to anything else to make it directly available.

iam:
  ui:
    visibility:
      ad: ok
      local: ok
      mrt: icon
      apikey: icon

iam.ui.order

Optional This controls the order in which identity providers are shown on the login screen.

iam:
  ui:
    order:
      - ad
      - apikey
      - local
      - mrt