Managing Users in SL1 PowerFlow

Download this manual as a PDF file 

This section describes how to configure authentication for PowerFlow to allow access to multiple users with a variety of roles and permissions.

This section also describes how to use the Admin Panel page () to manage user group access to the PowerFlow user interface. Only users with the Administrator role for the PowerFlow system can edit this page.

This section covers the following topics:

Configuring Authentication with PowerFlow

SL1 PowerFlow version 2.0.0 or later supports the following authentication methods:

  • Local Authentication. The same local Administrator user (isadmin) is supported by default with 2.0.0 or later installations. If you are migrating from a previous version of PowerFlow to version 2.0.0 or later, you can log in and authenticate with the same user and password. Local authentication only supports the isadmin administrator user.
  • Basic Authentication. PowerFlow 2.0.0 or later continues to support Basic Authentication as well. Because the PowerFlow PowerPacks, diagnostic scripts, and the iscli tool continue to use Basic Authentication, ScienceLogic does not recommend disabling Basic Authentication with PowerFlow version 2.0.0 or later.
  • OAuth. Lets PowerFlow administrators use their own authentication providers to enforce user authentication and lockout policies. Authentication using a third-party provider, such as LDAP or Active Directory, requires additional configuration. For optimal security, ScienceLogic recommends that you disable the local Administrator user (isadmin) and exclusively use your own authentication provider.

  • Common Access Card (CAC) Authentication. Lets a PowerFlow user provide a CAC card through a browser to the PowerFlow root IP address. After identifying the CAC card, the ingress proxy verifies and authenticates the user. CAC authentication bypasses Dex authentication and does not use OIDC protocols.

Regardless of authentication strategy, authorization and role access is configured separately, based on user or user group. For more information, see Creating a User Group in PowerFlow.

The following topics describe how to configure each authentication strategy for PowerFlow:

User Interface Login Administrator User (Default)

The local Administrator user is the default login user for PowerFlow. The username is "isadmin" by default, and the password gets set during the ISO installation process. The PowerFlow administrator can change the default password or the Administrator user.

This authentication strategy allows authentication of the local Administrator user through the PowerFlow user interface. The "isadmin" user is the local Administrator by default, but you can change the username of the local Administrator to something other than "isadmin" if needed.

If you disable this authentication strategy, you must first configure an alternative provider to appropriately authenticate to the PowerFlow system and also configure a user or user group policy that has the Administrator role. If you disable this user without a second authentication provider configured, PowerFlow will not be able to authenticate any users.

To disable this user, set the following environment variable in the /etc/iservices/isconfig.yml file:

BASIC_AUTH: False

To change the local Administrator username, set the following environment variable in the /etc/iservices/isconfig.yml file:

BASIC_AUTH_USER: "username"

Before changing the local Administrator username, make sure that the user has Administrator permissions in the PowerFlow system. For more information, see User Groups, Roles, and Permissions.

ScienceLogic recommends that you use the same system-wide password for the local Administrator user, which is located in /etc/iservices/is_pass. To change this password, run the /opt/iservices/scripts/ispasswd script.

Alternatively, you can set a different password for the local Administrator user by setting the following environment variable in /etc/iservices/isconfig.yml:

BASIC_AUTH_PASSWORD: "BASIC_AUTH_PASSWORD"

Basic Authentication Using a REST Administrator User (Default)

Basic Authentication through a REST administrator user enables the local Administrator user to access the PowerFlow API through REST using Basic Authentication. This authentication strategy enables users to make queries through the API using <isadmin:password> basic authentication.

This Basic Authentication is enabled by default in PowerFlow 2.0.0 or later. The REST administrator uses the same environment variables and configuration as the user interface login Administrator user.

Basic Authentication is limited to only the local Administrator user. If your PowerFlow system is configured to use a different authentication provider, you must authenticate using OAuth 2.0 and a bearer token. For more information, see OAuth Client Authentication Using an Internal Provider.

This Basic Authentication user is enabled by default to support backward compatibility with any scripts or queries running against the versions of PowerFlow before 2.0.0. If you disable this authentication strategy, PowerPacks and end-user scripts will not be able to query or access the API unless they are updated to use OAuth 2.0 with bearer a token.

User Interface Login Using a Third-party Authentication Provider

This authentication strategy lets you set up user authentication through a third-party authentication provider, such as LDAP or Active Directory (AD). You configure additional providers and their connectors in the /etc/iservices/isconfig.yml file, following the Dex connector configuration described below. This authentication strategy is automatically disabled when no connectors are present in the configuration.

After you configure the providers, users can select one of the defined providers or the local Administrator authentication, and authenticate using that provider.

When using this authentication strategy, the PowerFlow system automatically retrieves the LDAP or AD groups to which the user belongs. You can use these groups can be used to apply specific role permissions. For more information, see Role-based Access Control (RBAC) Configuration.

By default, no third-party authentication providers are configured in PowerFlow.

Credentials for user authentication exist only with the third-party authentication provider, and the credentials are not imported into PowerFlow. The only information that PowerFlow retains for these users are the roles and permissions attached to the user names.

To configure a third-party authentication provider:

  1. Go to https://github.com/dexidp/dex#connectors and locate the connector type, such as LDAP or SAML 2.0, that you would like to use for authentication.
  2. Click the link for the connector type to view example configuration options for the connector.
  3. Update the /etc/iservices/isconfig.yml file and add a DEX_CONNECTORS section with the configuration for the connector you want to use. The DEX_CONNECTORS section in the isconfig.yml file is identical to the CONNECTORS section described in the Dex documentation.
  4. Re-deploy the PowerFlow stack and check for errors in docker service logs iservices_dexserver. If the dexserver starts successfully and PowerFlow is running, then PowerFlow has accepted the configuration.
  5. Next, log in to the PowerFlow system with a user provided by the newly configured authentication.
  6. Look for errors with searching users or user groups in the user interface or the Docker service logs.

For reference, the following is an example /etc/iservices/isconfig.yml file with an Active Directory authentication provider configured to look up users and their groups:

HOST_ADDRESS: 10.1.1.111
CLIENT_ID: isproxy
CLIENT_SECRET: knivq7uDPVORdrSlWJ0I4YiiwuQgGDsf9rMWquoInYs
SESSION_SECRET: BDLO2xPrBs_s-YkqY-j4lN6VPeBzyrVsYt_P10oWbn0
DB_HOST: couchbase.isnet,localhost 
BIND_DN: auser # this can be encrypted for security
BIND_PW: password # this can be encrypted for security
 
DEX_CONNECTORS:
- type: ldap
  # Required field for connector id.
  name: ldap
  id: ldap
  # Required field for connector name.
  config:
    host: rstcsdc01.sciencelogic.local:636
	# Host and optional port of the LDAP server in the form "host:port".
	# If the port is not supplied, it will be guessed based on "insecureNoSSL",
	# and "startTLS" flags. 389 for insecure or StartTLS connections, 636
	# otherwise.
			
    insecureNoSSL: false
	# The insecureNoSSL field is required if the LDAP host is not using TLS (port 389).
			
    insecureSkipVerify: true
	# If a custom certificate isn't provide, this option can be used to turn on
	# TLS certificate checks. As noted, it is insecure and shouldn't be used outside
	# of explorative phases.
			
    bindDN: '{{BIND_DN}}'
    bindPW: '{{BIND_PW}}'
	# The DN and password for an application service account. The connector uses
	# these credentials to search for users and groups. Not required if the LDAP
	# server provides access for anonymous auth.
	# Please note that if the bind password contains a `$`, it has to be saved in an
	# environment variable which should be given as the value to the bindPW field.
			
    usernamePrompt: silo credentials
	# The attribute to display in the provided password prompt. If unset, will
	# display "Username"
			
    userSearch:
	# User search maps a username and password entered by a user to a LDAP entry.	
      baseDN: OU=Domain User Accounts,DC=ScienceLogic,DC=local
	  # BaseDN to start the search from. 		
      filter: "(objectClass=user)"
	  # Optional filter to apply when searching the directory.			
      username: userPrincipalName
	  # username attribute used for comparing user entries.
	  # The following three fields are direct mappings of attributes on the user entry.
      idAttr: DN
	  # String representation of the user.
      emailAttr: userPrincipalName
	  # Required. Attribute to map to email.
      nameAttr: cn
	  # The nameAttr field maps to the display name of users. No default value.			
    groupSearch:
	# Group search queries for groups given a user entry. Group searches must match a user 
	# attribute to a group attribute. 
      baseDN: OU=Domain Groups,DC=ScienceLogic,DC=local
	  # BaseDN to start the search from.
      filter: "(objectClass=group)"
	  # Optional filter to apply when searching the directory.	
	  # The following list contains field pairs that are used to match a user to a group. 
	  # It adds an additional requirement to the filter that an attribute in the group 
	  # must match the user's attribute value.
      userAttr: DN
	  # The userAttr field is the attribute used from the user search query. 
	  # to match to an element of the group search.
      groupAttr: member
	  # The groupAttr field is the attribute of the group results that should match the userAttr value.
      nameAttr: cn
	  #  This value must exactly match the group defined in the IS Group configuration.

OAuth Client Authentication Using a Third-party Provider

OAuth Client Authentication provides user authentication with a configured third-party provider, such as LDAP or AD. This allows users to use clients authenticating with OAuth 2.0 bearer tokens to authenticate against their configured provider.

In PowerFlow 2.0.0 or later, the OAuth Client Authentication strategy is automatically enabled when a authentication provider is configured. You can configure this strategy using the same parameters as the User Interface Login Using a Third-party Authentication Provider.

The PowerFlow system provides discovery endpoints for all OAuth 2.0 required endpoints. The discovery address is: https://IS-IP:5556/dex/.well-known/openid-configuration.

Using these discovery endpoints, you can use an OAuth 2.0 client to generate a secure token using a third-party authentication provider. You can use the generated secure token as a bearer authentication token (specified in request headers) to authenticate and make requests.

The client_secret and session_secret are unique, randomly generated strings generated for each IS deployment. To obtain an OAuth 2.0 token, you will need these values, which you can find in the /etc/iservices/isconfig.yml file.

Basic Authentication Lockout Removal

PowerFlow 2.0.0 or later supports OAuth 2.0 with OpenID Connect, which lets PowerFlow administrators use third-party authentication providers, such as LDAP or Active Directory, to enforce user authentication and lockout policies.

PowerFlow continues to support Basic Authentication as well, but PowerFlow no longer enforces automatically locking out the isadmin user if that user has too many failed login attempts.

If you are concerned about removing the lockout functionality for the isadmin user, you can perform one of the following actions:

  1. Change the default username from isadmin to a different name to prevent brute force type attacks on the isadmin user.
  2. Disable Basic Authentication and use third-party authentication providers, such as your company's LDAP server, to enforce user authentication and lockout policies.

Before disabling Basic Authentication, make sure that all scripts or tools that query the PowerFlow API have been updated to use OAuth 2.0.

Common Access Card (CAC) Authentication

Enabling Common Access Card (CAC) authentication lets a PowerFlow user provide a CAC card through a browser to the PowerFlow root IP address. After identifying the CAC card, the ingress proxy verifies and authenticates the user. CAC authentication bypasses Dex authentication and does not use OIDC protocols.

Applying CAC Authorization

To enable Common Access Card (CAC) authorization on the PowerFlow system:

  1. Link to a valid server CA certificate:

  2. Set up Public-Key Cryptography Standards (PKCS) #11 in Firefox for your CAC card according to the following instructions: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/pkcs11.

    Use the certificates in step 1 for loading authorities.

  3. Add the corresponding server-ca secret into the gui container in the docker-compose file:

    gui:
  secrets
   - source: server-ca.crt
secrets:
 server-ca.crt:
   file: /etc/iservices/server-ca.crt

  4. Add the following line to /etc/iservices/isconfig.yml:

    CAC_AUTH: 'true'

Adding CRL to CAC Authentication

To add a certificate revocation list (CRL) to CAC authentication:

  1. Download an example CRL from this site: http://ca.pivkey.com/server-ca.crt.

  2. Install the following Synchronization PowerPack that contains a PowerFlow application that you can run to continually update CRL: http://repository.auto.sciencelogic.local/artifactory/pypi-local/is_syncpack_mud/1.0.0/is_syncpack_mud-1.0.0-py3-none-any.whl.

  3. Add the corresponding volume information to gui and syncpack_steprunner in the docker-compose file:

    syncpack_steprunner:
volumes:
...
- source: ca_crl
      target: /var/crl
      type: volume
gui:
...
volumes:
    - read_only: true
      source: ca_crl
      target: /var/crl
      type: volume
volumes:
...
  ca_crl: {}

  4. Restart the PowerFlow services.

  5. Install the MUD Synchronization PowerPack from step 2 and run the PowerFlow application to Fetch CRL.

    Alternatively, you can manually mount a PEM-formatted CRL file to /var/server-ca.crl.

  6. After the CRL is applied to the volume, update the configuration of /etc/iservices/isconfig.yml with the following line and then re-deploy:

    CAC_CRL: 'true'

CAC Authentication with LDAP

CAC authentication with LDAP uses the standard CAC authentication process, and it additionally searches the LDAP server for relevant groups of the user, which can be used for role-based access control (RBAC) checking later.

This authentication process uses the same DEX_CONNECTORS configuration settings for the configured LDAP/AD server and associated certificates to perform a search of the users' LDAP server. Using the search strings configured for Dex, if the CAC logic identifies group membership, the user session will be updated with their groups.

Environment Expectations

CAC authentication with LDAP requires the following:

  • The user must provide an Admin Bind DN and password to provide a search of the LDAP system.
  • The user from CAC will not attempt to be bound and authenticated to LDAP.
  • The end user has necessary certificates to form a trusted ldaps// connection. SSL certificate verification can be disabled, but is not recommended.
  • The administrator is aware of the LDAP environment, search attributes, and object classes necessary to link either a CAC user's SAN or CN to their group membership
  • Only SAN or CN is supported for group membership search.

Add LDAP to CAC Query

CAC authentication with LDAP requires ldapCA.pem, which is a file with the internal LDAP server CA chain. This will get concatenated to tls-ca-bundle.pem, the ca-trust bundle of the is_gui container.

To copy an LDAP CA certificate for verification:

  1. Create tls-ca-bundle.pem by running the following command:

    docker cp 0b26b93af179:/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem ~/ cat ldapCA.pem >> tls-ca-bundle.pem

  2. Use an SCP tool to move tls-ca-bundle.pem to /etc/iservices/.

Docker configuration: 

configs:
  tlsbundle:
    file: /etc/iservices/tls-ca-bundle.pem
...
  gui:
    read_only: true
    configs:
    - source: tlsbundle
      target: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
...
 

CAC Authentication with LDAP and SAN

CAC authentication with LDAP and SAN allows the user to use their Subject Alternative Name (SAN) value when performing group lookup.

To implement CAC authentication with LDAP and SAN , use the configuration variable called CAC_LDAP_SEARCH_BY. This environment variable specifies whether to use Subject Alternative Name (SAN) or Common Name (CN) for LDAP group membership searches when LDAP is enabled and when CAC_LDAP_VERIFY is enabled. The default value of this environment variable is san; use cn for Common Name in the environment variable section.

Role-based Access Control (RBAC) Configuration

Regardless of the authentication method you have chosen to use, the role-based permissions assigned to users is applied in the same way.

Assigning a Role to a Specific User

By applying a role permission to a single username in the admin panel, or through the API, permissions will be granted to any user who logs in through a provider matching that username.

Assigning Roles to a Specific User Group

By applying a role permission to a group name in the admin panel, or through the API, permissions will be granted to any user who logs in and is a member of the specified group.

For authentication to work properly, group_search must be configured in the authentication provider's connector information. When requesting authentication tokens, be sure to also request the groups claim.

If a user belongs to multiple groups, with varying permissions defined to each group, the user will be permitted to do all actions provided by the group that provides the most roles.

Viewing User and Group Information

After configuring your third-party authentication connector in Dex, you can run the following command to view the search strategy and group results for any user that attempts to authenticate by looking at the Dexserver logs:

docker service logs -f iservices_dex

Changing Roles and Permissions

To change roles and permissions through the PowerFlow user interface, go to the Admin Panel page () to create and edit the roles and permissions of the user groups. For more information, see Creating a User Group in PowerFlow.

To change roles and permissions through the API, refer to the swagger.yml file for API required parameters and endpoints to update roles and permissions.

Configuring Authentication Settings in PowerFlow

The following configuration settings can be configured and used with the PowerFlow authentication and authorization strategies:

  • DEX_CONNECTORS. This environment variable specifies which authentication providers Dex will use. For more information, see User Interface Login Using a Third-party Authentication Provider.
  • BASIC_AUTH_USER. This environment variable specifies the basic_auth and admin login username. For more information, see User Interface Login Administrator User.
  • BASIC_AUTH_PASSWORD. This environment variable specifies the basic_auth and admin login password. For more information, see User Interface Login Administrator User.
  • BASIC_AUTH. This environment variable specifies whether the local Administrator user will be enabled. For more information, see User Interface Login Administrator User.
  • CLIENT_ID. The IS client_id in use by default is isproxy, and you should not change this value.
  • CLIENT_SECRET. The client_secret is a randomly generated string unique to each PowerFlow deployment. In most configurations, you do not need to change this secret.

  • CAC_AUTH. This environment variable specifies whether to enable CAC certificate checking. If this is used, there should be a public CA certificate added as a server-ca.crt secret to the gui container. For more information, see CAC Authentication.

  • CAC_CRL. This environment variable specifies whether certificate revocation list (CRL) checking is enabled for the CAC client certificate. If this is true and updated, the user should must add a ca_crl:/var/ca_crl volume to both the gui and syncpacks_steprunner services.

  • CAC_LDAP_VERIFY. This environment variable specifies whether to enable lookup of group permissions based on the user Subject Alternative Name (SAN) or Common Name (CN) to the configured LDAP server. If this is configured, the user must configure an LDAP or AD server under the DEX_CONNECTORS environment variable.

  • CAC_LDAP_SEARCH_BY. This environment variable specifies whether to use Subject Alternative Name (SAN) or Common Name (CN) for LDAP group membership searches when LDAP is enabled and when CAC_LDAP_VERIFY is enabled. The default value of this environment variable is san; use cn for Common Name in the environment variable section.

  • BIND_DN. Use this encrypted value in the dex_connectors section when using LDAP as a connector.

  • BIND_PW. Use this encrypted value in the dex_connectors section when using LDAP as a connector.

User Groups, Roles, and Permissions

On the Admin Panel page (), you can edit and create user groups that define the different roles and permissions for your users. Depending on their assigned permissions, users have access to certain features, or they are blocked from certain features.

The available roles and permissions for PowerFlow include the following:

  • View. The user can view and get via the API the list of applications, the list of installed Synchronization PowerPacks, the dashboards, the reports, the configuration objects, and the results of application runs.

  • Execute. The user has all of the privileges of the View permission, but the user can also trigger application runs through the user interface or the API.
  • Configuration. The user has all of the privileges of the Execute permission, but the user can also add and edit configuration objects and modify the application variables.
  • Developer. The user has all of the privileges of the Configure permission, but the user can also add, copy, and edit step definitions; add, copy, and edit application definitions; and create Synchronization PowerPacks.
  • Administrator. The user has all of the privileges of the Develop permission, but the user can also add, install, activate, and delete Synchronization PowerPacks; delete applications, steps, and configuration objects; and access to (but not authorization to) the user interfaces for Couchbase, Flower, and RabbitMQ.

Additional information about roles and permissions in PowerFlow:

  • Roles in PowerFlow are automatically assigned to a user based on the user's group with the external provider (such as LDAP or AD) .
  • If a PowerFlow system does not have an external provider configured, such as LDAP or Active Directory, that PowerFlow system can only support a single isadmin Administrator user.
  • The only password saved in the PowerFlow system is the password for the isadmin Administrator user. All other user passwords are saved in the third-party authentication provider configured for PowerFlow.
  • The authentication configuration used by PowerFlow is also supported in SL1.
  • API queries made by users will also be checked for proper authorization.
  • The PowerFlow administrator can configure which users are in which roles.
  • The PowerFlow administrator can test and configure the LDAP and Active Directory settings to ensure that the settings work before proceeding.
  • The PowerFlow administrator can always log in with the isadmin Administrator user, even if the underlying LDAP provider is inaccessible.

Creating a User Group in PowerFlow

If you have the Administrator role, you can modify the permissions for each user group on the page. You cannot change the permissions for the user group to which you currently belong.

A user with the Administrator role can also create a user group and assign permissions to that group.

The only password saved in the PowerFlow system is the password for the isadmin Administrator user. All other user passwords are saved in the third-party authentication provider configured for PowerFlow.

To create a user group:

  1. In the PowerFlow user interface, go to the Admin Panel page ():

  1. Click Add User Group. The Create User Group window appears.

  1. Complete the following fields:
  • User Group Name. Type a name for this user group, without spaces. This is the name that the users in this group will use when logging in to PowerFlow.
  • Choose Permissions Group. Click Add Permission to select the permission to assign to this new user group. Your choices include Developer, Configuration, View, Execute, and Administrator, and these choices are defined in User Groups, Roles, and Permissions.

  1. Click Create User Group. The group is added to the Admin Panel page.
  2. If you want to give a user group more permissions, select the empty checkbox () for that role from the Admin Panel page. You must have the Administrator role to change these settings.
  3. If you want to remove permissions from a user group, select the highest level role, which has a blue check mark (). The role to the right (with fewer permissions) becomes the new role for that user group.

Managing User Sessions

A user with the Administrator role can use the Session Management pane of the Admin Panel page () to monitor which users have been logged into the PowerFlow system. The admin user can end active sessions as needed. Non-admin users can view user sessions, but they cannot end those sessions.

When an administrator ends a session for a user by clicking the End sessions button, that user is redirected to the PowerFlow login page.

Enabling Session Management

Session management is disabled by default. You can use the following set of configuration variables to enable and configure session management. You can set these variables in the PowerFlow configuration file /etc/iservices/isconfig.yml or on the services environment variables:

  • ENABLE_SESSION_STORAGE. Set to true to enable session management with default values. This variable is set to false by default.

  • SESSION_IDLE_TIME: Specify the idle time in seconds. The default is 900 seconds. This value and the following values should be declared as a string.

  • SESSION_RENEW_EVERY: Specify the automatic session regeneration time in seconds. The default is 600 seconds.

  • SESSION_ABSOLUTE_TIME: Specify the longest time allowed for a session, in hours, such as 25h. You can also use minutes, such as 60m. This variable uses Dex notation. The default is 25 hours.

  • CONCURRENT_SESSIONS_BY_USER. Specify the number of sessions that can be running at the same time, by number of users. The default is 30 users.

    When the number of user sessions is exceeded, the user trying to log in is redirected to a "Session limit has been reached" page, and then the user is returned to the login page.

Authentication and Authorization for Services Used by PowerFlow

The PowerFlow administrator can control the level of access to the specific PowerFlow services, including Couchbase and RabbitMQ. Authentication for these services is provided by Dex authentication, which is already used for role-based access control (RBAC) in PowerFlow.

This feature requires LDAP/AD authentication for the PowerFlow system. For more information, see OAuth Client Authentication Using a Third-party Provider.

Couchbase

  • Couchbase authentication. To access the Couchbase user interface, a user must log in to PowerFlow first, using his or her PowerFlow credentials. If the user is authorized to access the Couchbase user interface, the user can add port "8091" to the PowerFlow URL, and the user will be automatically redirected to the Couchbase user interface.

  • Couchbase authorization. The roles and user groups defined in PowerFlow are applied to the Couchbase user interface based on the default user group policies. The PowerFlow administrator can update these user policies to specify which groups can access Couchbase.

    Couchbase authorization uses the following default permissions:

  • Administrator. The user has access to all resources at all levels.
  • Developer. The user can add and edit buckets and documents, but the user cannot delete anything.
  • Configuration. The user can add and delete indexes and add nodes to Couchbase.
  • Execute. The user has read-only access.
  • View. The user cannot login to the Couchbase user interface. This was explicitly set that way as Couchbase is the main database for PowerFlow.

RabbitMQ

  • RabbitMQ authentication. RabbitMQ authentication works the same as PowerFlow authentication and Couchbase authentication.
  • RabbitMQ authorization. RabbitMQ authorization uses the following default permissions:

  • Administrator: The user has access to all resources, at all levels, and the user can create internal users and policies. These policies do not impact PowerFlow users.

  • Developer: The user can create resources and read all resources on all vhosts.

  • Configuration: The user can create queues and exchanges only in the default vhost, but the user can read queues and exchanges on all vhosts.

  • Execute: The user can read queues and exchanges on all vhosts, but the user cannot create or configure any resources.

  • View: The user can only view queues and exchanges on the default vhost.

If you want to disable the auto-login feature for RabbitMQ and Couchbase, you can set the force_auth_validation environment variable to "true" under the GUI container configurations in the docker-compose file. Setting this variable to "true" allows you to access the Couchbase or RabbitMQ user interface to address issues without needed to authorize. If the flag is missing or set to "false", the auto-login feature continues to work.