Advanced Cluster Security - Authentication

Security Advanced Cluster Security

- Thomas Jungbauer Thomas Jungbauer ( Lastmod: 2024-05-08 ) - 4 min read

Red Hat Advanced Cluster Security (RHACS) Central is installed with one administrator user by default. Typically, customers request an integration with existing Identity Provider(s) (IDP). RHACS offers different options for such integration. In this article 2 IDPs will be configured as an example. First OpenShift Auth and second Red Hat Single Sign On (RHSSO) based on Keycloak

Prerequisites

  1. OpenShift 4 Cluster

  2. Advanced Cluster Security v3.66+

  3. Red Hat SSO Operator installed

While RHSSO will be installed during this article, only default and example values are used. These are by no means examples for a production system.

Introduction

Advanced Cluster Security comes with several default roles, which can be assigned to users:

System roleDescription

Admin

This role is targeted for administrators. Use it to provide read and write access to all resources.

Analyst

This role is targeted for a user who cannot make any changes, but can view everything. Use it to provide read-only access for all resources.

Continuous Integration

This role is targeted for CI (continuous integration) systems and includes the permission set required to enforce deployment policies.

None

This role has no read and write access to any resource. You can set this role as the minimum access role for all users.

Sensor Creator

Red Hat Advanced Cluster Security for Kubernetes uses this role to automate new cluster setups. It includes the permission set to create Sensors in secured clusters.

Scope Manager

This role includes the minimum permissions required to create and modify access scopes.

It is possible to create custom roles.

Configure RHACS Authentication: OpenShift Auth

It is assumed that RHACS is already installed and login to the Central UI is available.

  1. Login to your RHACS and select “Platform Configuration” > “Access Control”

  2. From the drop down menu Add auth provider select OpenShift Auth

    ACS AuthProvider
    Figure 1. ACS Auth Provider

  3. Enter a Name for your provider and select a default role which is assigned to any user who can authenticate.

    It is recommended to select the role None, so new accounts will have no privileges in RHACS.

    With Rules you can assign roles to specific users, based on their userid, name, mail address or groups.

    For example the user with the name poweruser gets the role Admin assigned.

Verify Authentication with OpenShift Auth

  1. Logout from the Central UI and reload the browser.

  2. Select from the drop down OpenShift Auth

    ACS LoginOpenShiftAuth
    Figure 2. ACS Login

  3. Try to login with a valid OpenShift user.
    Depending on the Rules which have been defined during previous steps the appropriate permissions should be assigned.
    For example: If you login as user poweruser the role Admin is assigned.

Configure Red Hat Single Sign On

The following steps will create some basic example objects to an existing RHSSO or Keycloak to test the authentication at RHACS. Skip to step #5 if you have Keycloak already up and running and would like to reuse an existing client.

The RHSSO operator (or Keycloak) is installed at the namespace single-sign-on.

  1. Create an instance of Keycloak

    apiVersion: keycloak.org/v1alpha1
kind: Keycloak
metadata:
  name: example-keycloak
  namespace: single-sign-on
spec:
  externalAccess:
    enabled: true
  instances: 1

  2. Create a Realm
    This will create a Realm called Basic

    apiVersion: keycloak.org/v1alpha1
kind: KeycloakRealm
metadata:
 name: example-keycloakrealm
 namespace: single-sign-on
spec:
 instanceSelector:
   matchLabels:
     app: sso
 realm:
   displayName: Basic Realm
   enabled: true
   id: basic
   realm: basic

  3. Login into Red Hat SSO
    Get the route to your RHSSO instance:

    oc get route keycloak -n single-sign-on --template='{{ .spec.host }}'

# keycloak-single-sign-on.apps.cluster-29t8z.29t8z.sandbox677.opentlc.com

    and log into the Administration Interface.

  4. Extract the admin password for Keycloak

    The secret name is build from "credential"<keycloak-instance-name>

    oc extract secret/credential-example-keycloak -n single-sign-on --to=-

# ADMIN_PASSWORD
<you password>
# ADMIN_USERNAME
admin

  5. Be sure to select your Realm (Basic in our case), goto Clients and select a ClientID.

    1. In this example we select account

      ACS SSOClientConfig
      Figure 3. ACS Login
      Of course you can create or use any other Client.

    2. Enable the option Implicit Flow

  6. Get the Issuer URL from your realm. This is typically your:
    https://<KEYCLOAK_URL>/auth/realms/<REALM_NAME>;

    For Example: https://keycloak-single-sign-on.apps.cluster-29t8z.29t8z.sandbox677.opentlc.com/auth/realms/basic

Create Test Users

In RHSSO create 2 user accounts to test the authentication later.

  1. Goto Users and create the users:

    1. User: acsadmin

      First Name: acsadmin

    2. User: user1

      First Name: user 1

You can set any other values for these users. However, be sure to set a password for both, after they have been created.

Configure RHACS Authentication: RHSSO

It is assumed that RSACS is already installed and login to the Central UI is available.

  1. Login to your RHACS and select “Platform Configuration” > “Access Control”

  2. From the drop down menu Add auth provider select OpenID Connect

    1. Enter a “Name” for your provider i.e. “Single Sign On”

    2. Leave the “Callback Mode” to the “Auto-Select” setting

    3. Enter your Issuer URL

    4. As Client ID enter account (or the ClientID you would like to use)

    5. Leave the Client Secret empty and select the checkbox Do not use Client Secret which is good enough for our tests.

      Remember the two callback URL from the blue box. They must be configured in Keycloak.

    6. Select a default role which is assigned to any user who can authenticate.

      It is recommended to select the role None, so new accounts will have no privileges in RHACS.

    7. With Rules you can assign roles to specific users, based on their userid, name, mail address or groups.

    8. For example the user with the name acsadmin (which have been created previously in our RHSSO) gets the role Admin assigned.

The final settings are depict in the following image:

ACS OpenIDConfig
Figure 4. ACS Login

Continue RHSSO Configuration

What is left to do is the configuration of redirect URLs. These URLs are shown in the ACS Authentication Provider configuration (see blue field in the image above)

  1. Log back into RHSSO and select “Clients” > “account”

  2. Into Valid Redirect URLs enter the two URLs which you saved from the blue box in the RHACS configuration.

Troubleshoot: Test Login

In RHACS you can test the login to you SSO.

  1. Goto "Platform Configuration" > "Access Control"

  2. Click the button "Test login"

    A popup will appear which asks you to enter SSO credentials. The connection to RHSSO will be validated:

    ACS TestSSOAuth
    Figure 5. ACS Test SSO

Verify Authentication with OpenShift Auth

  1. Logout from the Central UI and reload the browser.

  2. Select from the drop down Single Sign On

    ACS LoginSSOAuth
    Figure 6. ACS Login SSO

  3. Try to login with a valid SSO user.
    Depending on the Rules which have been defined during previous steps the appropriate permissions should be assigned.
    For example: If you login as user acsadmin the role Admin is assigned.

See Also:

  • Introducing AdminNetworkPolicies –

    Classic Kubernetes/OpenShift offer a feature called NetworkPolicy that allows users to control the traffic to and from their assigned Namespace. NetworkPolicies are designed to give project owners or tenants the ability to protect their own namespace. Sometimes, however, I worked with customers where the cluster administrators or a dedicated (network) team need to enforce these policies. Since the NetworkPolicy API is namespace-scoped, it is not possible to enforce policies across namespaces. The only solution was to create custom (project) admin and edit roles, and remove the ability of creating, modifying or deleting NetworkPolicy objects. Technically, this is possible and easily done. But shifts the whole network security to cluster administrators. Luckily, this is where AdminNetworkPolicy (ANP) and BaselineAdminNetworkPolicy (BANP) comes into play.

  • Setup & Configure Advanced Cluster Security using GitOps –

    Today I want to demonstrate the deployment and configuration of Advanced Cluster Security (ACS) using a GitOps approach. The required operator shall be installed, verified if it is running and then ACS shall be initialized. This initialization contains the deployment of several components: Central - as UI and as a main component of ACS SecuredClusters - installs a Scanner, Controller pods etc. Console link into OpenShift UI - to directly access the ACS Central UI Job to create an initialization bundle to install the Secured Cluster Job to configure authentication using OpenShift Let’s start …​

  • Setup & Configure Compliance Operator using GitOps –

    In the previous articles, we have discussed the Git repository folder structure and the configuration of the App-Of-Apps. Now it is time to deploy our first configuration. One of the first things I usually deploy is the Compliance Operator. This Operator is recommended for any cluster and can be deployed without any addition to the Subscription. In this article, I will describe how it is installed and how the Helm Chart is configured.

  • Secrets Management - Vault on OpenShift –

    Sensitive information in OpenShift or Kubernetes is stored as a so-called Secret. The management of these Secrets is one of the most important questions, when it comes to OpenShift. Secrets in Kubernetes are encoded in base64. This is not an encryption format. Even if etcd is encrypted at rest, everybody can decode a given base64 string which is stored in the Secret. For example: The string Thomas encoded as base64 is VGhvbWFzCg==. This is simply a masked plain text and it is not secure to share these values, especially not on Git. To make your CI/CD pipelines or Gitops process secure, you need to think of a secure way to manage your Secrets. Thus, your Secret objects must be encrypted somehow. HashiCorp Vault is one option to achieve this requirement.

  • Automated ETCD Backup –

    Securing ETCD is one of the major Day-2 tasks for a Kubernetes cluster. This article will explain how to create a backup using OpenShift Cronjob.

Copyright © 2020 - 2024 Toni Schmidbauer & Thomas Jungbauer