What is even access control management and why should you care about it?

As the observability space grows, more and more people find value in tools like IBM Instana, but even in a democratized approach to all this valuable information, not everyone gets to do everything. In its simplest form, admins and users are the first distinction between user access control.
But as organizations grow and start to include more data, gaining value from this data becomes more apparent for more and more users. Does everyone really need to see everything? Should admins make all the changes and create configurations every time a new perspective on the data is needed? Do we just allow free rein for everyone and trust they will do the right thing?
In some cases, these might even work, but the reality is even without strict regulations forcing your hand, managing users' access on a more refined level will become necessary.

This trend of growing need for more granular controls on user access and easier manageability at scale has reached the limits of our current group based approach in Instana and we've been working hard in the background for the last several months on a new structure to better support our customers.

What is a Team?

We've started the process of discovery, trying to understand how are users managed, what is the basis of reality we can hook in to and will make most sense for most customers. In almost all cases, the recurring phrase we heard was Team or a group of people working together on a fairly specific topic at some length of time.
Such teams have a defined area of responsibility shared among their members, but those members can have different tasks to do, different proficiencies or different Roles.
Based on this, we've defined the new Instana Team concept, which is a group of users, who have a shared scope of responsibility, but individuals might have different levels of access on the shared scope.

What is a Role?

Once the organizing structure of people was becoming clear, we needed to have a way to declaring the "levels of access". The classical setup of a Role-Based Access Control (or RBAC) presented itself as a clear winner here, as the different levels of access are in most cases a repeating configuration. An SRE, a senior app developer or a quality assurance engineer really mostly does the same tasks, regardless of which team they belong to. The set of roles can be as simple as Owners (admin) and Default (viewers or users) all the way to defining each set of tasks as their own role. As roles can be stacked easily, the management of these roles becomes future-proof and scalable.

So how does this all work? What happens to my groups?

It was important for us to make sure, if you are not making changes to your configuration, than users' access and experience doesn't change. While moving most existing groups into a role was trivial (and will be found under the list of roles) we are keeping groups with a limited scope unchanged, but marked as such in the list of roles. Until you create Teams and assign users to them, your users will not see any changes.

What was previously all configured as part of a group will now become a combination of role(s) a user has in their team. This also allows a user to have different roles on different teams to provide flexibility in access configuration.
Once a user becomes a member of a team, they will have the option to switch their Scope from default scope (which maintains the existing behavior) to the Team scope. This allows a setup, where a user is allowed to configure their Smart Alerts, but only on applications which are part of their team scope.

This change now allows for much broader self-servicing capabilities for teams, segmenting their team scope from the unit and allowing users to have unique roles on this scope without having to provide too broad access on everything else and the chance for the user to break something that doesn't belong to them.

How will I know what belongs to which team now?

To make the self-servicing aspect even easier, we're also introducing Team associations. Think of these as a limited set of tags, that can be used to declare responsibility over configurations users can create. For admins this makes it easier to see who manages a certain synthetic test or which team will be receiving alert notifications on a certain Alert channel. Using the team association, those users with a role to create configurations in the team can make sure what is being added will be visible to their teammates without additional administrator involvement.
Team associations can also be useful even if you are not planning to limit the access scope of your teams, enabling better collaboration inside Instana, by clearly showing who is responsible for which configuration.

This all sounds great, when can I try this already?

While we're proud of today's milestone of 300 Instana releases put into production, changes of this size come with unexpected delays. The public preview of the Teams feature is expected as part of release 301, with the functionality described in this blog with a few limitations on team associations. (Alert channels, custom dashboards, synthetic tests and credentials being the first configurations to support this)

Were you looking for these changes already? Do you use limited groups today? Or are you content with the free for all access today?
Let us know in the comments!