[Granular Auth] Introduce Granular Auth for Elastic Agent Cluster Profile and Elastic Profile

1. Permission set for Creating a Cluster Profile

<role name=”cp_admins”>
	<policy>
		<allow action=”administer” type=”cluster_profile”>cp_*</allow>
	</policy>
	<users>
		<user>cp_admin1<user>
		<user>cp_admin2<user>
	</users>
</role>

Implicit permissions

If a user is able to administer a Cluster Profile, they will be able to administer all elastic profiles within it.

1. Permission set for viewing a Cluster Profile

<role name=”cp_viewers”>
	<policy>
		<allow action=”view” type=”cluster_profile”>cp_*</allow>
	</policy>
	<users>
		<user>cp_view1<user>
		<user>cp_view2<user>
	</users>
</role>

Implicit permissions

If a user is able to view a Cluster Profile, they will be able to view all elastic profiles within it. I suggest only view as these can be elevated by making someone administer an EP or all.

1. Permission set for viewing EP in a cluster profile

A user with the below policy can view all Elastic Profiles within cluster profile CP1.

<allow action="view" type="elastic_profile">cp_1:*</allow>

Implicit permissions

View permission on cp_1

A user with the below policy can view all Elastic Profiles within cluster profile CP1.

<allow action="view" type="elastic_profile">cp_1:ep_*</allow>

Implicit permissions

View permission on cp_1

A user with the above policy can view all Elastic Profiles

<allow action="view" type="elastic_profile">*:*</allow>

Implicit permissions

View permission on all cluster profiles

A user with the below policy can view all Elastic Profiles matching the wildcard ep_* within cluster profile CP1

<allow action="view" type="elastic_profile">cp_*:ep_*</allow>

Implicit permissions

View permission on cluster profiles matching the pattern cp_*

1. Permission set for creating an EP in a cluster profile A user with the below policy can administer all Elastic Profiles within cluster profile CP1.

<allow action="administer" type="elastic_profile">cp_1:*</allow>

Implicit permissions

View permission on cp_1

A user with the below policy can administer all Elastic Profiles within cluster profile CP1.

<allow action="administer" type="elastic_profile">cp_1:ep_*</allow>

Implicit permissions

View permission on cp_1

A user with the above policy can administer all Elastic Profiles

<allow action="administer" type="elastic_profile">*:*</allow>

The above should also be allowed to be represented as

<allow action="administer" type="elastic_profile">*</allow>

Implicit permissions

View permission on all cluster profiles

A user with the below policy can administer all Elastic Profiles matching the wildcard ep_* within cluster profile CP1

<allow action="administer" type="elastic_profile">cp_*:ep_*</allow>

Implicit permissions

View permission on cluster profiles matching the pattern cp_*

@arvindsv @maheshp @GaneshSPatil @kritika-singh3

[kritika-singh3]

Ok. In midst of so many options and paths, the safest path is the one you mentioned @GaneshSPatil .

[GaneshSPatil]

@kritika-singh3

NOTE: These reports’ permissions are mentioned for Elastic Agent Plugins implementing Elastic Agent v5 extension (and not for v4). Also, none of the GoCD supported v5 plugins implement the Plugin Status Report.

Here are some complexities implementing the above-mentioned permission:

1. The plugins page is only accessible to the super admins. Does this mean now cluster admins get to see all the plugins? or only the elastic agent plugins?? If we choose to show only elastic agent plugins, will it create confusion as to why other plugins are not visible??
2. The * administer permission is just logical permission for all cluster profiles. And a plugin status report is per plugin. Hence, what we should be checking is, whether the current user has admin permissions on all the cluster profiles of the given plugin. This would require us to check permission against each cluster profile during policy evaluation.

This permission would get a little more complex to understand when elastic agent plugins implementing v4 extension (azure, marathon) comes into the picture:

For such plugins:

• On the plugins page, Plugin Settings can only be configured by Super Administrators (as there is no granular auth support for plugin settings)
• But, the Plugin Status Report can be accessed by Cluster Administrators of no-op cluster.

Hence, decided to keep the plugin related entity access only for super administrators.