Today we are proud to announce that the highly anticipated RBAC (Role-Based Access Control) is going live. In a few words, RBAC will eventually replace our implicit User Level (Member, Admin, SuperAdmin) permission system and offer a much more granular approach to user permissions. Read on to get the details and the shape of things to come in that department.

If you are a Kentik Administrator in your company who will be tasked with managing user permissions, please take the time to read this KB article which outlines the changes from the Legacy User Level-based system, the new RBAC capabilities, and the gotchas from the migration.

What is RBAC?

Role-Based Access Control is a set of User Permission capabilities that allow Kentik Portal Admins to adopt a granular approach to what actions each user can perform in the Portal.
While RBAC will eventually fully replace our User Level model, both will coexist for a while as we port Portal capabilities from one model to the other (which will take a few quarters).
An additional framework, named Permission Overrides is also in place for a limited number of Portal modules: Connectivity Costs and Synthetic Monitoring. It allowed users to set fine-grain permissions for these aforementioned modules only: this capability has been phased out with this RBAC release and replaced by native RBAC permissions.

How does RBAC work?

Users can access RBAC settings in the company settings menu, as depicted below:

Within this settings screen, RBAC administrators will be allowed to create Roles.
Each Role contains a configurable list of permissions, such as "View Connectivity Costs", and "Edit Synthetic Tests"... and a user can be assigned as many roles as desired. When a user has multiple roles assigned to them, the resulting permissions will be the union of all permissions described in all the assigned roles.

The following screenshot illustrates a role named "Administrators", which contains permissions.

The following screenshot is that of a User Settings (from the User Management screen) displaying which roles and resulting permissions are assigned to a given user. Notice that this user has two roles: "Members" and "Connectivity Costs Viewer"

RBAC uses an "implicit deny" model
It's important to notice that this RBAC permission model is based on "Implicit Deny", which means that there are no "Prevent user from doing this..." type of configuration: a user can only perform an RBAC-regulated action if they have the related permission in any of the roles they have been assigned.

What does the initial release of RBAC encompass? 

The initial goal for this first release is to get rid of the legacy Permission Overrides model, which we are therefore sunsetting. The initial set of Portal areas covered by RBAC are listed below:

• RBAC Management:
  View permission by user, Create Roles, View Roles for the Company, Create Roles, Update Roles, Delete Roles, Assign User to Roles, Remove Users from Roles
• Connectivity Costs:
  View the Connectivity Costs workflow, Configure Providers and Costs
• Synthetic Monitoring Agents:
  Create Agents (Register), View Agents, Update Agents, Delete Agents
• Synthetic Monitoring Tests:
  Create Tests, View Test results, Update Tests configuration, Delete Tests

Introducing Kentik-Managed Roles

For convenience, we have also added the notion of Kentik-Managed Roles: these are roles that are exclusively editable by Kentik. The idea behind these is to provide a simple alternative to cover all existing permissions in one role leveraging Reasonable Defaults.
Whenever a new area of the Kentik Portal is folded into the RBAC engine, reasonable defaults for this area of functionality will be updated to these Kentik-Managed Roles - making it somewhat seamless to our users who are currently satisfied with the User Level model.

There are currently 3 such roles, and they mimic the current Member, Admin, SuperAdmin User Levels. For new users, one of these 3 roles will be by default assigned upon user creation based on the Legacy User Level.

Important Note
By default, the Connectivity Costs workflow is entirely disabled for users with the Member Kentik-Managed Role - as a lot of you have mentioned our permissions around it were too loose. New users created with a 'Member' User Level will require an additional custom Role to access the workflow. Since existing users without permission overrides already had access to the Connectivity Costs workflow, we've added a "Connectivity Costs Viewer" role to their profile so they can keep access to the workflow.

What's next in RBAC world ? 

Our initial RBAC release establishes the foundation of the RBAC permission engine. In the coming quarters we'll build on this foundation by expanding the RBAC model into new areas:

• We are working to extend Labels to multiple areas of the portal beyond Devices, Synthetics Agents, and Synthetics tests (see Test Control Center), and we want to extend RBAC permissioning to apply to content grouped together by users using labels.
• In Q4, we will extend label-based RBAC permissions to Synthetics agents and tests, and will shortly follow with Dashboards and Saved Views, allowing the permissions for content created by users to be managed both centrally and granularly.
• Our soon-to-be-released Credentials Vault will be upgraded shortly with the ability to manage secrets based on labels.

More than anything, we would love to hear your thoughts on which area of Kentik Portal you would like us to work on implementing next, so please do let us know!

A lot of you have been asking for a feature allowing you to embed a Dashboard URL containing the value of the Guided Mode Parameter in your external systems.
This is now possible, read on!

Dashboards always come with this URL format: https://portal.kentik.<com|eu>/v4/library/dashboards/<dashboard_id>
Let's say your Guided Mode dashboard pivots around a Destination Interface Provider dimension.

In this example, you can access this dashboard with the parameter pre-filled with the value my_provider using this URL:
https://portal.kentik.<com|eu>/v4/library/dashboards/<dashboard_id>/guided?provider=my_provider

Finding the parameter name to use in the URL after the guided?<parameter>=<value> portion may be a little tricky: parameters in Guided Mode do not 1:1 correspond to the SRC|DST|SRC_or_DST dimensions you are used to in Data Explorer, because Guided Mode considers families of Dimensions, and discard the directionality. Here are a few examples:

• Using SRC, DST (or both) ASN as a parameter will result in using as_number as a parameter name
• Using SRC, DST (or both) AS_PATH as a parameter will result in using bgp_aspath as a parameter name
• Using SRC, DST (or both) Provider as a parameter will result in using provider as a parameter name

The extensive list of URL parameters is available below for your consumption:

- application
- as_group
- as_name
- as_number
- aws_acc_id
- aws_priv_dns
- aws_pub_dns
- aws_region
- aws_subnet_id
- aws_vm_id
- aws_vm_name
- aws_vm_type
- aws_vpc_id
- aws_zone
- az_inst_id
- az_inst_name
- az_region
- az_rsrc_grp
- az_sub_id
- az_sub_name
- az_vnet
- bgp_aspath
- bgp_community  
- bot_net
- cdn
- city
- cloud_provider
- cloud_service
- connectivity_type
- country
- device
- device_label
- dns_query
- eth_mac
- gce_proj_id
- gce_region
- gce_vm_name
- gce_vpn_snn
- gce_zone
- interface_capacity
- interface_desc
- interface_group
- interface_id
- interface_name
- ip
- market
- network_boundary
- port
- provider
- region
- service_name
- service_provider
- service_type
- site
- site_market
- tag
- threat_list
- traffic_org
- vlan
- vrf

Upon popular request, we've added a new agent to the Kentik platform – Kentik BGP proxy (kbgp) – which enables BGP enrichment of flow data to internal network devices without requiring global IP connectivity. Before kbgp, customers could only establish BGP sessions with devices with an assigned public IP address. Via kbgp, BGP enrichment can now extend to flow data generated from all internal areas of your network, further enhancing network troubleshooting for on-prem and campus environments. Read on for details!

Kentik BGP proxy (kbgp) is a Kentik agent that can proxy BGP peering sessions between customer devices inside the customer’s network and Kentik over the Internet. The kbgp is deployed inside the customer’s private network. The customer devices are able to establish BGP peering with the kbgp, which will multiplex and relay BGP packets in real time to Kentik. The result would be the same as if the devices are peering directly with Kentik.

The functionality is achieved similarly to the functionality that is performed by kproxy, which collects flows locally inside the customer’s network and securely exports them to Kentik inside an HTTPS tunnel.

Without kbgp, customer devices can only establish BGP sessions with Kentik over the Internet, which requires that the customer device has a public IP address assigned. With the use of kbgp, multiple registered devices can have BGP peering with a single kbgp. The BGP session packets are carried over a secure gRPC session to Kentik, where the BGP session is logically established and the data is transferred. kbgp does not store any BGP state or BGP routes, making this agent lightweight and requiring very few resources.

The image below shows the logical diagram of kbgp usage inside a customer’s network

The key benefits of deploying kbgp in a Kentik-monitored network include:

• Kentik will be able to add BGP context to the flow data from internal network devices that don't have global IP connectivity
• The BGP data is secured and encrypted during the transfer from the customer's network to Kentik

At the moment, kbgp does not appear under the Kentik Agents section in the Settings menu, but we are actively working on a way to display the agent within the UI. For more information about the kbgp installation, configuration, and troubleshooting, please check out our kbgp KB article and let us know your feedback in the comments. 

In the coming months, we're going to consistently streamline the Settings screen as you have known it.

Today, we're sharing the 1st iteration of this broader project – Organization Settings. Kentik users now have a new Organization Settings menu displayed next to User Settings at the top right of the navigation bar, making it easier and faster to manage company and organization-wide settings.

Let's start with what's new in the Organization Settings menu:

• Licenses moved from the top Navigation menu to this menu
• All of the additional links in this menu have been moved over from the Settings screen 
• You'll also notice that your Kentik Company ID (CID) is now mentioned at the top right of this menu

The User menu is right next to it and now looks like this – the entries are self-explanatory. User Name, Email, and your Kentik Portal User ID (UID) are now displayed in this menu.

Thanks to relocating many of these entries from the Settings page, the Settings page now displays a more streamlined and clean look. Additionally, we've created a dedicated section for all Alerting settings to be housed – making the page much more homogenous and easy to navigate for users. 

Let us know how you feel about these changes! 

A lot of our users have been asking for a way to export a spreadsheet of a certain amount of configuration items from Kentik Portal, namely:

• Devices list as in "Settings > Networking Devices" 
• Sites list as in "Settings > Manage Sites"
• Users list as in "Settings > Manage Users"

This is now available on all of these screens by clicking the "Action > Export > Data Table (.csv)" on all of these three screens

Upon popular request, we've added a few functionalities to the Subscription capabilities that you can see throughout the portal when you click on the [Share] button.
Read on.

• You can now set a custom filename for any report that you want to subscribe to, with the option to add a specific Date Marker to it.
• We have made the email recipients of a subscription more granular, now including: To, CC and BCC

As Connectivity Costs is one of our most in-demand workflows, we've spent some extra time this quarter to address a much-requested change from our users: Billing Cycle Day and Contract End Dates have now been moved down from the Provider level to the Cost Group level within the provider. Read on.

Billing Cycles and Contract End dates are now a Cost Group level attribute

The main pet peeve our users had was that it is pretty common to have multiple IP Transit contracts with the same provider with a different billing date and contract end date. This was indeed a design flaw on our end when we initially released the workflow, and we're pleased to announce we have now corrected it.

All provider contract dates have been transferred to the child cost group objects within all providers and you can now modify them at will at a cost group level.

Let's see what it looks like, as the impacts on the Connectivity Cost workflow UI are multiple.

The new Cost Group Settings panel now contains Billing Cycle Start Date and Contract End Date fields. 

These are now visible on the cost group cards within a provider.

Provider Cards in the Provider Management screen now display these dates as part of each Cost Group entry.

The landing page Calendar Side panel now shows cards that correspond to cost groups, instead of providers, when it comes to Invoices Due and Contract Expiries. 

On the Provider Details Screen, cost groups with a Billing Cycle Date in the past are displayed in solid color, while the ones with a Billing Cycle Date in the future are displayed as estimates with a striped color. 

All Cost Group entries on the Provider Details table now show a progress bar displaying how far from the Billing Cycle Date each Cost Group is at the time of viewing, with a color that varies as we get closer to the billing date.

Download the entire SNMP Sample Set for Billing reconciliation

What do you do when the Kentik cost displayed at the end of your billing cycle doesn't match your providers' invoice? Generally, you enter a dispute which requires you to provide your own calculation together with the SNMP 5min samples it's based on.

We have made this possible in this addition to the Cost Group side panel in a providers' screen, where in the click of a button, the entire set of data samples for all interfaces (In and Out) gets generated as a CSV file for you to look at, also containing interface names, descriptions, device...

...and wait, there's more

While at it, we've also made the "Suggested Provider" right-side panel collapsible for those of our users did not want to see it in the Manage Providers screen:

We are excited to announce Version 1.0 of Kentik Map for GCP, which provides an analogous experience to the AWS and Azure maps in Cloud.

While the concept is largely the same, there are some differences in the GCP map organization compared to our AWS and Azure maps based on the way resources are organized in GCP.

For example, in contrast to the AWS topology map, which groups VPCs by region, the GCP map groups regions by VPC. Each region has its subnets listed beneath it.

The searchable GCP map displays traffic and routing data for the resources shown. We enable support for historical views back into your topology and metadata in GCP.

Visualizations from the GCP map include:

• VPN gateways with associated on-prem and cloud routers, networks, regions, subnets, interconnect attachments, and VM interfaces
• Static link paths for on-prem routers and external VPN gateways
• Traffic links generated from subnets and internet types
• Aggregated regional traffic classified as inbound, outbound, or internal

In the coming months, we will continue building GCP observability to achieve parity with our AWS and Azure offerings, adding functionality such as security group support. 

Our platform aims to provide customers full support for all clouds with a consistent user experience. Kentik Cloud abstracts away the differences in cloud network interfaces to maintain cohesive multi-cloud workflows in the Kentik Portal.

Setup instructions for the GCP Map are here in our Knowledge Base.

As hinted in one of our last updates about password complexity constraints, starting on June 1st, 2023 users relying on plain password authentication will be required to rotate their password at regular intervals.

Between tomorrow (May 9th, 2023) and June 1st, 2023, users whose preferred login method is currently plain password authentication will see this warning appear upon login, which will not show again once discarded.

This will only apply to password-authenticated users - the following authentication methods will not be impacted:

• SSO users
• 2Factor Users (TOTP or Yubikey)

Kentik recommends using these preferred, stronger authentication methods.

However, companies will still be allowed to change this setting via the Settings > Access & Security > Authentication & SSO screen if they so desire.

In this config screen, SuperAdmins will be allowed to:

• Select a different frequency between 90, 120, 180 and 365 days
• Completely disable password expiration (not advised)

As asked by our users, password reset will prevent users from re-using any of the five previous values.

Kentik now supports the collection of the NetFlow and IPFIX timestamp fields (starting kproxy v7.38.0). The additional 3 fields are available to be viewed in the Raw Flow Viewer:

• Flow Start - Timestamp of the flow start
• Flow End - Timestamp of the flow end
• Duration - Calculated duration of the flow as Flow Start - Flow End

NetFlow v5 and v9

In the case of the NetFlow v5 and v9, Start and End Flow timestamps are calculated using System Uptime and Unix Seconds fields from the NetFlow header and the following fields from Flow records:

IPFIX

In the case of the IPFIX, the timestamps are determined in the following two ways:

1. Using flowStartSysUpTime, flowEndSysUpTime and systemInitTimeMilliseconds fields:

   ID	Name	Type	Description	Units
   21	flowEndSysUpTime	unsigned32	The relative timestamp of the last packet of this Flow. It indicates the number of milliseconds since the last (re-)initialization of the IPFIX Device (sysUpTime). sysUpTime can be calculated from systemInitTimeMilliseconds.	milliseconds
   22	flowStartSysUpTime	unsigned32	The relative timestamp of the first packet of this Flow. It indicates the number of milliseconds since the last (re-)initialization of the IPFIX Device (sysUpTime). sysUpTime can be calculated from systemInitTimeMilliseconds.	milliseconds

   Both fields in the description refer to the additional field which is equivalent to the SysUpTime:

   ID	Name	Type	Description	Units
   160	systemInitTimeMilliseconds	dateTimeMilliseconds	The absolute timestamp of the last (re-)initialization of the IPFIX Device.	milliseconds

   
   

2. Using some of the IPFIX-specific fields for the flow start and flow end timestamps. Not all device’s IPFIX implementation used these fields, but if they are present, they are preferred and used:

   ID	Name	Type	Description	Units
   150	flowStartSeconds	dateTimeSeconds	The absolute timestamp of the first packet of this Flow.	seconds
   151	flowEndSeconds	dateTimeSeconds	The absolute timestamp of the last packet of this Flow.	seconds
   152	flowStartMilliseconds	dateTimeMilliseconds	The absolute timestamp of the first packet of this Flow.	milliseconds
   153	flowEndMilliseconds	dateTimeMilliseconds	The absolute timestamp of the last packet of this Flow.	milliseconds
   154	flowStartMicroseconds	dateTimeMicroseconds	The absolute timestamp of the first packet of this Flow.	microseconds
   155	flowEndMicroseconds	dateTimeMicroseconds	The absolute timestamp of the last packet of this Flow.	microseconds
   156	flowStartNanoseconds	dateTimeNanoseconds	The absolute timestamp of the first packet of this Flow.	nanoseconds
   157	flowEndNanoseconds	dateTimeNanoseconds	The absolute timestamp of the last packet of this Flow.	nanoseconds
   158	flowStartDeltaMicroseconds	unsigned32	This is a relative timestamp only valid within the scope of a single IPFIX Message. It contains the negative time offset of the first observed packet of this Flow relative to the export time specified in the IPFIX Message Header.	microseconds
   159	flowEndDeltaMicroseconds	unsigned32	This is a relative timestamp only valid within the scope of a single IPFIX Message. It contains the negative time offset of the last observed packet of this Flow relative to the export time specified in the IPFIX Message Header.	microseconds

sFlow

sFlow is packet sampling technology, which means that there is no flow, hence no flow start or flow end time.

sFlow also does not contain any timestamp, so the behavior is the following:

• Flow Start: save the time of arrival/processing of the sFlow packet
• Flow End - same as Flow Start
• Duration - 0

Raw Flow Viewer

In the Raw Flow Viewer, these additional flow timestamps need to be selected as Dimensions to be shown in the output, as shown below: