Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roles, Users, and Permissions in MTA for the mta-documentation repo #25

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
92 changes: 72 additions & 20 deletions docs/topics/mta-7-installing-web-console-on-openshift.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
//
// * docs/web-console-guide/master.adoc

:_content-type: PROCEDURE
:_mod-docs-content-type: PROCEDURE
[id="mta-7-installing-web-console-on-openshift_{context}"]

= Installing the {ProductName} {WebName}
Expand All @@ -16,7 +16,7 @@ The {ProductShortName} Operator is a structural layer that manages resources dep
[id="openshift-persistent-volume-requirements_{context}"]
== Persistent volume requirements

To successfully deploy, the {ProductShortName} Operator requires 3 RWO persistent volumes (PVs) used by different components. If the `rwx_supported` configuration option is set to `true`, the {ProductShortName} Operator requires an additional 2 RWX PVs that are used by Maven and the hub file storage. The PVs are described in the table below:
RichardHoch marked this conversation as resolved.
Show resolved Hide resolved
To successfully deploy, the {ProductShortName} Operator requires 2 RWO persistent volumes (PVs) used by different components. If the `rwx_supported` configuration option is set to `true`, the {ProductShortName} Operator requires an additional 2 RWX PVs that are used by Maven and the hub file storage. The PVs are described in the following table:

.Required persistent volumes
RichardHoch marked this conversation as resolved.
Show resolved Hide resolved
[cols="25%,25%,25%,25%", options="header"]
Expand All @@ -41,17 +41,13 @@ To successfully deploy, the {ProductShortName} Operator requires 3 RWO persisten
|RWO
|Keycloak back end database

|`pathfinder postgresql`
|1 GiB
|RWO
|Pathfinder back end database

|`cache`
|100 GiB
|RWX
|Maven m2 cache; required if the `rwx_supported` configuration option is set to `true`
|====

[id="installing-mta-operator-and-ui_{context}"]
== Installing the {ProductName} Operator and the {WebName}

You can install the {ProductName} ({ProductShortName}) and the {WebName} on Red Hat OpenShift versions 4.13-4.15.
Expand Down Expand Up @@ -210,6 +206,7 @@ mirror:
helm: {}
----

[id="memory-requirements-mta-openshift-local_{context}"]
== Memory requirements for running {ProductShortName} on Red Hat OpenShift Local

When installed on https://developers.redhat.com/products/openshift-local/overview[Red Hat OpenShift Local], {ProductShortName} requires a minimum amount of memory to complete its analysis. Adding memory makes the analysis process run faster. The table below describes the {ProductShortName} performance with varying amounts of memory.
Expand All @@ -220,7 +217,6 @@ When installed on https://developers.redhat.com/products/openshift-local/overvie
|Memory (GiB)
|Description


|`10`
|{ProductShortName} cannot run the analysis due to insufficient memory

Expand Down Expand Up @@ -264,25 +260,81 @@ To prevent out-of-memory events and protect nodes, use the `--eviction-hard` set

The amount of memory available for running pods on this node is 28.9 GiB. This amount is calculated by subtracting the `system-reserved` and `eviction-hard` values from the overall capacity of the node. If the memory usage exceeds this amount, the node starts evicting pods.


[id="rhsso-overview-mta_{context}"]
== Red Hat Single Sign-On
{ProductShortName} delegates authentication and authorization to a
https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6[Red
Hat Single Sign-On] (RHSSO) instance managed by the {ProductShortName} operator. Aside from controlling the full lifecycle of the managed RHSSO instance, the {ProductShortName} operator also manages the configuration of a dedicated
https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html/server_administration_guide/configuring_realms[realm] that contains all the roles and permissions that {ProductShortName} requires.
{ProductShortName} delegates authentication and authorization to a https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6[Red Hat Single Sign-On] (RHSSO) instance managed by the {ProductShortName} operator. Aside from controlling the full lifecycle of the managed RHSSO instance, the {ProductShortName} operator also manages the configuration of a dedicated https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html/server_administration_guide/configuring_realms[realm] that contains all the roles and permissions that {ProductShortName} requires.

If an advanced configuration is required in the {ProductShortName} managed RHSSO instance, such as https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html/server_administration_guide/user-storage-federation#adding_a_provider[adding
a provider for User Federation] or https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html/server_administration_guide/identity_broker[integrating
identity providers], users can log into the RHSSO https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html/server_administration_guide/configuring_realms#using_the_admin_console[Admin
Console] through the `/auth/admin` subpath in the `{LC_PSN}-ui` route. The admin credentials to access the {ProductShortName} managed RHSSO instance can be retrieved from the `credential-mta-rhsso` secret available in the namespace in which the {WebName} was installed.
If an advanced configuration is required in the {ProductShortName} managed RHSSO instance, such as https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html/server_administration_guide/user-storage-federation#adding_a_provider[adding a provider for User Federation] or https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html/server_administration_guide/identity_broker[integrating identity providers], users can log into the RHSSO https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html/server_administration_guide/configuring_realms#using_the_admin_console[Admin Console] through the `/auth/admin` subpath in the `{LC_PSN}-ui` route. The admin credentials to access the {ProductShortName} managed RHSSO instance can be retrieved from the `credential-mta-rhsso` secret available in the namespace in which the {WebName} was installed.

A dedicated route for the {ProductShortName} managed RHSSO instance can be created by setting the `rhsso_external_access` parameter to `True` in the *Tackle CR* that manages the {ProductShortName} instance.

For more information, see
https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html/server_administration_guide/red_hat_single_sign_on_features_and_concepts[Red
Hat Single Sign-On features and concepts].
https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html/server_administration_guide/red_hat_single_sign_on_features_and_concepts[Red Hat Single Sign-On features and concepts].


[id="mta-roles-personas-users-permissions_{context}"]
=== Roles, Personas, Users, and Permissions

{ProductShortName} makes use of three roles, each of which corresponds to a persona:

.Roles and personas
[cols="50%,50%", options="header"]
|====
|Role
|Persona

|`tackle-admin`
|Administrator

|`tackle-architect`
|Architect

|`tackle-migrator`
|Migrator
|====

The roles are already defined in your RHSSO instance. You do not need to create them.

If you are an {ProductShortName} administrator, you can create users in your RHSSO and assign each user one or more roles, one role per persona.

[id="mta-roles-personas-ui-views_{context}"]
==== Roles, personas, and access to {WebName} views

Although a user can have more than one role, each role corresponds to a specific persona:

* Administrator: An administrator has all the permissions that architects and migrators have, along with the ability to create some application-wide configuration parameters that other users can consume but cannot change or view. Examples: Git credentials, Maven `settings.xml` files.

* Architect: A technical lead for the migration project who can run assessments and can create and modify applications and information related to them. An architect cannot modify or delete sensitive information, but can consume it. Example: Associate an existing credential to the repository of a specific application.

* Migrator: A user who can analyze applications, but not create, modify, or delete them.

As described in xref:mta-ui-interface-views[User interface views], {ProductShortName} has two views, *Administration* and *Migration*.

Only administrators can access *Administration* view. Architects and migrators have no access to *Administration* view, they cannot even see it.

Administrators can perform all actions supported by *Migration* view. Architects and migrators can see all elements of *Migration* view, but their ability to perform actions in *Migration* view depends on the permissions granted to their role.

The ability of administrators, architects, and migrators to access the *Administration* and *Migration* views of the {ProductShortName} {WebName} is summarized in the table below:

.Roles vs. access to {ProductShortName} views
[cols=",,,",options="header",]
|===
|Menu
|Architect
|Migrator
|Admin
|Administration
|No
|No
|Yes
|Migration
|Yes
|Yes
|Yes
|===

=== Roles and Permissions
[id="mta-roles-permissions_{context}"]
==== Roles and permissions

The following table contains the roles and permissions (scopes) that {ProductShortName} seeds the managed RHSSO instance with:

Expand Down
8 changes: 4 additions & 4 deletions docs/web-console-guide/master.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ include::topics/templates/document-attributes.adoc[]
//Inclusive language statement
include::topics/making-open-source-more-inclusive.adoc[leveloffset=+1]

[id="mta-6-ui-guide-introduction"]
[id="mta-ui-guide-introduction"]
== Introduction

// About the {WebConsoleBookName}
Expand All @@ -25,17 +25,17 @@ include::topics/mta-what-is-the-toolkit.adoc[leveloffset=+2]
// About the {WebName}
include::topics/about-the-user-interface.adoc[leveloffset=+2]]

[id=mta-6-ui-interface-views]
[id=mta-ui-interface-views]
== User interface views

The {ProductName} ({ProductShortName}) {WebName} has two views:

* Administration view
* Migration view

In *Administration* view, you configure the instance environment, working with credentials, repositories, HTTP and HTTPS proxy definitions, custom migration targets, and issue management.
In *Administration* view, administrators can configure the instance environment, work with credentials and repositories, define HTTP and HTTPS proxies, specify custom migration targets, manage issues, and add custom assessment questionnaires.
RichardHoch marked this conversation as resolved.
Show resolved Hide resolved

In *Migration* view, you perform application assessments and analyses, review reports, and add applications for assessment and analysis.
In *Migration* view, all authorized users can review reports, add applications for assessment and analysis. perform application assessments and analyses, create migration waves, view issues that could potentially impact migration, view the status of analysis and discovery tasks through Task Manager. The permissions of the different user roles -- administrators, architects, and migrators -- vary in this view.

// == Administration view
// include::topics/mta-web-administration-view.adoc[leveloffset=+1]
Expand Down