Authentication and Access Control

The communication between the K8s cluster and AppViewX KUBE+ takes place through a REST API, and it is authenticated. AppViewX provides several authentication modes to access its API.

Authentication

  • Basic Authentication: AppViewX offers multiple modes of authentication for accessing its API. Users can create a dedicated user for authentication, either an external user (LDAP, RADIUS and TACACS) or an internal user created in AppViewX. For more information on Basic Authentication, refer to Platform User guide.

  • OAuth 2.0 (Service Account): Users have the option to create a service account that is enabled through AppViewX OAuth 2.0. They can then obtain the client ID and client secret from the service account, which can be used for authentication purposes. Once the ClientID and ClientSecret are configured in cert-orchestrator, they will be used for authentication. If the existing ClientSecret expires, cert-orchestrator will renew it by using the current ClientID and ClientSecret. The new ClientSecret will then be stored and used for subsequent authentication with AppViewX. For more information on OAuth 2.0, refer to Platform User guide.

Access Control

Specific permissions to access modules and carry out tasks within each AppViewX module are assigned by each role. Roles are exclusively assigned to user groups. Any user groups assigned to a role will automatically inherit all the associated permissions. User groups can also be assigned more than one role.

KUBE+ simplifies role-based access control by providing Out Of the Box (OOB) roles for KUBE+ features. These predefined roles can be cloned, enabled, or disabled, but not updated or deleted. For more granular control, administrators can create custom roles, which can be fully managed (updated, deleted, enabled, and disabled). Users can then be assigned either OOB roles or custom roles to align with their specific permissions, streamlining the management of user access and permissions for various personas within KUBE+.

KUBE-Application-User: For DevOps/Application users/CloudOps teams to perform Certificate Lifecycle Management for their applications (or) business units.

KUBE-PKI-Administrator: For Infosec and PKI teams to define and enforce PKI policies for their Kubernetes environments.

KUBE-cert-orchestrator: Role to be mapped to the service account or user used for deployment of Cert-Orchestrator for performing CLM operations on individual Kubernetes clusters.

As previously explained, when deploying Cert-Orchestrator within the Kubernetes cluster for access control, it's necessary to follow these steps:

  1. Create a user or service account and associate it with the User Group.
  2. Assign the KUBE-cert-orchestrator role to the User Group.
  3. Additionally, ensure that the super access resource is linked to the User Group.
  4. Ensure MFA (Multi Factor Authentication) is disabled for this user since it is used for API access.
Note: When a user onboards the cluster using Easy Onboarding and selects "Download Credentials," the KUBE+ platform automatically performs steps 1 through 3. This includes creating the OAuth service account, mapping the default KUBE service user group, the OOB KUBE cert-orchestrator, and the super access resource.

For detailed instructions to perform any actions on role, see Platform User Guide.