Introducing SOC Insights for BloxOne Threat Defense: Boost your SOC efficiency with AI-driven insights to eliminate manual work and accelerate investigation and response times. Read the blog announcement here.

Security Blog

126418927-660x454.jpg

RBAC and a Little bit of Authentication

Author:  Philip Parker, Infoblox Senior Technical Marketing Engineer

 

There are many features that come as a surprise to our customers, and we've often heard, "didn't know you could do that".  One of these features is Role Based Access Control (RBAC). Its intent is to allow a role based permissions model for controlled delegation of administration.

 

The first thing to get started is to authenticate yourself with the Grid Master.  Infoblox has a number of options all leading to a logged-in session with an administrative group assigned.  The session could be a GUI, API, or even TAXII. Transport security is typically provided by TLS.

 

Authentication methods include Active Directory, Certificate Authentication Services (CAS), LDAP, RADIUS, SAML, TACACS+, and of course Local (on-board) accounts.


Documentation is available through the Help panel in your Grid Manager GUI or the Infoblox Support Portal (https://support.infoblox.com/) and is an excellent resource. The information for managing authentication services and permissions can be found in the section titled “Managing Administrators”.

 

Authenticated

Role(s) are the next permissions feature.  There are a number of predefined roles like DNS, DHCP, DTC, Grid, SAML, PKI etc and you can have multiple roles (custom and/or pre-defined) defining the permissions of a group, or even have a blend of roles and custom permissions.  In the case of conflicts, there is a permissions overlap review panel to see conflicts.

 

Permissions Overview

Permissions Overview.jpg

 

This is an overview of the GUI page associated with Admins, Groups, Roles, and Permissions.  You can see that a list of all the groups and roles is available.

 

Role Permissions

Role Permissions.jpg

 

In this example, we selected the DTC Admin role and the assigned permissions are listed.  Note that the predefined roles cannot be modified, but they can be cloned and/or deleted (not recommended).  When you create a role, you can add from Global permissions sets, and/or specific Object permissions. NIOS applies permissions hierarchically in a parent-child structure.

 

Manage Global Permission

Manage Global Permission.jpg

 

 

Available Global Permissions follow the theme of Roles,  while the number of groups may vary depending on the features enabled in the Grid and version of NIOS.  Each group will have multiple resources/functions with permissions enabled for either the Read/Write, Read-Only, or Deny conditions.  Deny is the default when none are selected.

 

Create Object Permissions

Create Object Permissions.jpg

 

Object Permissions allow you to assign permissions to an individual object, allowing an admin to set permissions down to say an A record object, or a Host record object.  There are 80+ object types.

 

Group Permissions

Group Permissions.jpg

 

Keep It Simple

It is important to note that the flexible nature of Roles and Permissions, (global and object) allows you to create a very complex permissions model.  While robust, this can make managing and troubleshooting permissions more complicated than is sometimes needed.

 

Some of our largest customers have a simple set of groups and roles.  They use Web based front ends (example Django) to do WAPI queries, and filter on objects that the user may need and are allowed to change.

 

For example, imagine a printer admin that can clear leases, reservations and edit fixed addresses, but only on IP addresses in the ranges defined for their building/site.  WAPI is used to obtain a list of possible printer IP addresses from a DHCP/reserved range where an extensible attribute matches the building where the user is physically located, and you can be reassured that they only update the IP addresses or DHCP ranges that they are responsible for and nothing else.

 

The admin group being used for WAPI access can start by being generic for DHCP permissions, or even a finer focus by only allowing access to IPv4 Fixed Addresses and IPv4 Ranges.  The user may be restricted from directly communicating with your Infoblox server/Grid by the use of Group ACL's, thereby limiting the users access from the Web application's IP network/address. This gives you greater security and control over how the users access your Infoblox services.



Summary

Providing access to administrators based upon their administrative and operational needs is important to allow delegation/distribution of administrative duties.  By use of permissions based upon roles, least-privilege access can be easily achieved. Use of the RESTful web API (WAPI) allows you to remove the need for GUI access when localized specific access is required.  

Showing results for 
Search instead for 
Did you mean: