Administering Red Hat Managed Integration 2

Red Hat Managed Integration 2

For Red Hat Managed Integration 2

Red Hat Customer Content Services

Abstract

This document provides instructions for configuring and managing Red Hat Managed Integration 2.

Preface

This document provides instructions for Managed Integration administrators to:

  • Understand the Managed Integration cluster environment
  • Configure Managed Integration services for production scenarios
  • Customize the Managed Integration cluster

Chapter 1. Introduction to user management

In Managed Integration, all users have a role and belong to a particular group. You should understand these roles and groups so that you can manage users, and provide them with the appropriate permissions.

All Managed Integration users belong to the rhmi-developers group. Within this group, users can have either dedicated-admin or developer roles. The dedicated-admin role has elevated permissions and is one of the core OpenShift Dedicated roles.

1.1. Managed Integration Administrators

Managed Integration administrators have the dedicated-admin role. This role enables you to administer the Managed Integration cluster, and provide developers with the necessary permissions to use managed services.

As an administrator with the dedicated-admin role, you can do the following:

Red Hat Openshift

  • Work with namespaces
  • View all namespaces
  • Edit and delete your own namespaces
  • Edit and delete non-managed namespaces

Single Sign-On

  • Manage users and permissions in the master realm
  • Create realms
  • Administer user-created realms

Red Hat 3scale API Management

  • Elevate user permissions to an administrator level
  • Edit routes
  • View Pod logs in the 3scale namespace
  • Create a product in the 3scale console

Red Hat Fuse Online

  • "View" role in the Fuse namespace

Red Hat AMQ Online

  • Create, read, update, delete, and list custom resources

1.2. Managed Integration Developers

With the developer role, you can create namespaces in which to develop your cloud-native, integrated applications, and use the Customer Application SSO instance instance to secure your applications.

As a developer, you can do the following:

Red Hat Openshift

  • Create, edit, and delete own namespaces

Single Sign-On

  • Access the console
  • Create realms

Red Hat Fuse Online

  • "View" role in the Fuse namespace

1.3. Granting 3scale admin privileges to users

As an administrator who is a member of the dedicated-admins group, you have administrator privileges in 3scale. However, developers do not. You must explicitly grant 3scale administrator permissions to Managed Integration developers.

Procedure

  1. Log in to the Solution Explorer.
  2. Navigate to the 3scale console from the Manage APIs item.
  3. Grant administrator permissions to developers.

Chapter 2. Configuring Managed Integration services

Managed Integration includes pre-installed component applications that developers can use to develop cloud-native, integrated applications. As an administrator, you can configure these component applications so that developers can use them for production scenarios.

2.1. Enabling developers to secure customer applications

Managed Integration includes an instance of Red Hat Single Sign-On to enable you to protect the applications that you deploy on your cluster.

Red Hat manages this instance; however, all administrators have admin-level privileges to configure this instance to perform tasks such as:

  • Creating users in the master realm
  • Creating new realms
  • Managing realms

    By default, developers can create new realms. Administrators can administer any realms that developers create, and can disable realm creation.

Important

A user named admin manages the Red Hat Single Sign-On instance. Do not delete this user.

2.1.1. Disabling realm creation

By default, a developer can create a realm in the Customer Application SSO instance. This section describes how to disable this permission. You might want to disable this permission in a production cluster.

Prerequisites

  • You are an administrator who is a member of the dedicated-admins group.

Procedure

  1. Log in to the Solution Explorer.
  2. Navigate to the Customer Application SSO instance from the Protect customer applications item in the Solution Explorer.
  3. When prompted, choose the Administration Console.
  4. Choose Groups from the menu for the Master realm.
  5. Select the rhmi-developers group.
  6. Click Edit from the User Groups menu.
  7. Choose the Role Mappings tab.
  8. Select create-realm in the Assigned Roles panel.
  9. Click Remove selected to remove that role from the rhmi-developers group.

Verification

  1. To verify the change, log in to the Customer Application SSO instance as a developer.
  2. Make sure you cannot create a realm.

2.2. Configuring AMQ Online for production

If you plan to use AMQ Online in Managed Integration, you need to create an AMQ Online configuration for production. You must edit and apply YAML files using the command line (CLI) tools to configure AMQ Online.

This section provides general guidance on configuring AMQ Online for production usage in Managed Integration.

Prerequisites

  • You have the OpenShift CLI (oc) installed locally.

Procedure

  1. Configure AMQ Online in Managed Integration as described in Configuring AMQ Online.

    • The name of the AMQ Online project in your cluster is redhat-rhmi-amq-online.
    • You must log in as an administrator.
  2. Configure your address space to use an external authentication service as shown in the address space example using an external authentication service.

    Note

    The authentication services are configured by the AMQ Online service operator and are specified when creating an address space.

Additional resources

Chapter 3. Managing Solution Patterns

As an administrator, you can customize the list of Solution Patterns that developers can access in Solution Explorer.

3.1. Subscribing to Solution Pattern content

You can display a list of the Solution Patterns you are subscribed to on the Solution Explorer home page. Any administrator who is a member of the dedicated-admins group can add Solution Patterns to your cluster. Use the following procedure to list the Solution Patterns from the Git repositories you are subscribed to, on the Solution Explorer homepage.

Prerequisite

  • You are an administrator who is a member of the dedicated-admins group.

Procedure

  1. Log in to Solution Explorer.
  2. Click the gear icon in the top right.
  3. Click the Solution Pattern content tab.
  4. Enter the URLs of the Solution Pattern Git repositories you want to add to your cluster using the following syntax:

    https://github.com/<org>/<repo>.git

    where <org> is the name of your GitHub organization and <repo> is the name of your repository.

    1. List URLs in the order you want them to appear in the Solution Explorer.
    2. Enter one URL per line.
    3. To include a specific branch, append #<branch-name> to the URL. For example:

      https://github.com/<org>/<repo>.git#version-one
      Note

      To remove a Solution Pattern, delete the corresponding URL from the list.

  5. Click Save. This triggers an automatic refresh of the Solution Explorer.
  6. When the deployment is complete, refresh your browser. You should now see new Solution Patterns available from the dashboard.
  7. The Solution Explorer does not automatically update when changes are made to the Git repository.

    Refresh the Solution Explorer to view the changes:

    1. Click the gear icon in the top right to display the Application settings screen.
    2. Click Save to trigger a refresh of the Solution Explorer.
    3. Refresh the browser when the Solution Explorer refresh is complete.
    4. Navigate to the Solution Patterns tab to see the updated content.
Note

You can access the Git repository that contains the Solution Pattern source code by clicking the Repository link in the All Solutions Patterns tab in the Solution Explorer.

Additional resources

Chapter 4. Setting network policies

Network policies specify how groups are allowed to communicate with each other and other network endpoints. In your Managed Integration cluster, you define network policies to control how namespaces, the Managed Integration services, and customer applications communicate with each other.

To set a network policy, you must create and apply a NetworkPolicy Custom Resource object in the Managed Integration cluster. You can create NetworkPolicy objects to set the following types of network policies in your Managed Integration cluster:

Note

Network policies are additive. If multiple policies are created, the network policies are restricted to what is allowed by the union of those policies' ingress and egress rules.

4.1. Enabling communication between managed services and customer applications

You can create NetworkPolicy objects to define granular rules describing the Ingress network traffic that is allowed for projects in your cluster. By default, when you create projects in a cluster, communication between the projects is disabled.

This procedure describes how to enable communication for a project so that Managed Integration services (such as 3scale), can access customer applications.

Prerequisites

  • You have installed the OpenShift command-line interface (CLI), commonly known as oc.

Procedure

  1. Log in to the cluster using the oc login command.
  2. Use the following command to change the project:

    $ oc project <project_name>

    where <project_name> is the name of a project that you want to accept communications from other projects.

  3. Create a NetworkPolicy object:

    1. Create a allow-from-middleware-namespaces.yaml file.
    2. Define a policy in the file you just created, such as in the following example:

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-middleware-namespaces
      spec:
        podSelector:
        ingress:
          - from:
              - namespaceSelector:
                  matchLabels:
                    integreatly-middleware-service: 'true'
    3. Run the following command to create the policy object:

      $ oc create -f allow-from-middleware-namespaces.yaml -n <project>
      
      networkpolicy "allow-from-middleware-namespaces" created

Additional resources

4.2. Enabling communication between customer applications

You can enable communication between user applications.

Prerequisites

  • You have installed the OpenShift command-line interface (CLI), commonly known as oc.

Procedure

  1. Log in to the cluster using the oc login command.
  2. Use the following command to change the project:

    $ oc project <project_name>

    where <project_name> is the name of a project that you want to accept communications from other projects with the label project=myproject.

  3. Create a NetworkPolicy object:

    1. Create a allow-from-myproject-namespaces.yaml file.
    2. Define a policy in the file you just created, such as in the following example.

      This policy enables incoming communication for a specific project (myproject):

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-myproject-namespace
      spec:
        podSelector:
        ingress:
          - from:
              - namespaceSelector:
                   matchLabels:
                     project: myproject
  4. Run the following commands to create the policy object:

    $ oc create -f allow-from-myproject-namespace.yaml -n <project>
    networkpolicy "allow-from-myproject-namespace" created

Additional resources

4.3. Enabling communication between managed services and projects

By default, when you create projects in a cluster, communication between the projects is disabled. This procedure describes how to enable communication for a project.

Prerequisites

  • You have installed the OpenShift command-line interface (CLI), commonly known as oc.

Procedure

  1. Log in to the cluster using the oc login command.
  2. Use the following command to change the project:

    $ oc project <project_name>

    where <project_name> is the name of a project that you want to accept communications from other projects.

  3. Create a NetworkPolicy object:

    1. Create a NetworkPolicy.yaml file.
    2. Define a policy in the file you just created, such as in the following example.

      This policy enables incoming communication for all projects in the cluster:

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: allow-all
      spec:
        podSelector:
        ingress:
        - {}
      Note

      This policy configuration enables this project to communicate with all projects in the cluster.

    3. Run the following command to create the policy object:

      $ oc create -f <policy-name>.yaml -n <project>

Additional resources

4.4. Disabling communication from a managed service to a project

By default, your projects are created with a template that allows communication from a managed service. For example, Red Hat 3scale API Management can communicate with all of your projects by default. You can disable that communication.

Prerequisites

  • You have a project you want to isolate from the managed services.

Procedure

  1. Log in to the cluster using the oc login command.
  2. Use the following command to change the project:

    $ oc project <project_name>

    where <project_name> is the name of a project that you want to isolate from the managed services.

  3. Create a NetworkPolicy object:

    1. Create a deny-all.yaml file.
    2. Define a policy in the file you just created, such as in the following example:

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: deny-all
      spec:
        podSelector: {}
        ingress:
          - from:
              - namespaceSelector:
                  matchLabels:
                    integreatly-middleware-service: 'true'
    3. Run the following command to create the policy object:

      $ oc create -f <policy-name>.yaml -n <project>

Additional resources

Revised on 2020-09-17 09:14:11 UTC

Legal Notice

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.