Security - Frontier Kubernetes Platform

How Security is Implemented within Frontier Kubernetes Platform (FKP)

FKP is dedicated to security ranging from services of your organization’s Frontier Management Cluster (FMC) to client-side applications such as Frontier CLI/Outpost. Following enterprise security best practices, FKP is hardened with military-grade security, including access control via single sign-on, encrypted data addresses, and a network policy quota. FKP conforms to NSA/CISA Kubernetes security hardening guidelines and provides FIPS 140-2 ( FIPS 140-3 when adopted) compliant containers. All container images that are part of the platform, including Day-2 applications, undergo scanning for Common Vulnerabilities and Exposures (CVE) before every major and minor release. Servers and virtual machines (VM), for Kubernetes Control Plane nodes and Worker nodes have the necessary certifications and controls to comply with DISA-STIG guidelines.

Service Mesh

FKP provides service mesh integration leveraging Linkerd, including advanced networking capabilities such as multi-cluster and cross-cluster service discovery, load balancing, and security, across a variety of hybrid cloud, multi-cloud, and multi-cluster environments.

Active Directory Integration: Keycloak

Active Directory (AD) Domain Services (DS) is a structured data store of objects such as users. This can contain information for user accounts such as their username, password, email, phone number, etc. With AD, these users will be able to connect to network resources and services. In this case, we will be using this capability to integrate active directory with Keycloak.X. FKP currently utilizes Keycloak.X (powered by Quarkus and FIPS 140-2 compliant) for authentication and authorization for services within the FMC. Defense Information Systems Agency (DISA) recommends use of Keycloak due to it’s ease of integration with AD. For FKP, users imported into Keycloak using the AD integration will be granted access in using FKP services within their organizations. In prevention of transactions within the active directory or keycloak server, the goal for FKP is to eventually use Linkerd for mutual TLS with zero-trust to be established between the containerized host (Keycloak) to a non-containerized host (AD) whenever they support and release service mesh expansion in the future.

Services Roles and Authorization

OAuth 2.0 is an authorization framework that enables the Frontier applications to obtain limited access to user accounts on an HTTP service. The OAuth 2.0 protocol provides API security through scoped JWT access tokens. Frontier CAPI management services will validate and accept these JWT access tokens to enable authentication and authorization inside of your Frontier Management Cluster (FMC) without the need of sharing the management cluster’s kubeconfig.

OAuth 2.0 enables you to delegate authorization, while OIDC enables you to retrieve and store authentication information about your end users. OIDC extends OAuth 2.0 by providing user authentication and single sign-on (SSO) functionality. This will allow the FMC to restrict access of certain actions based on the permissions authorized by the employee user’s roles.

There are six roles total that are featured with FKP. These roles are:

• Frontier Administrator
• Core Project Administrator
• Project Administrator
• Core Cluster Administrator
• Cluster Administrator
• User

Each of these six will be authorized access to certain actions pending on which level these roles are assigned. There are three levels we will be taking a look at that can be found in the image diagram above:

• FMC Level
• Project Level
• Cluster Level

These levels of FKP services and their respective roles will be further discussed and dived into in the following sub-sections below.

FMC Level Authorization

The FMC is the root level and base for all actions conducted in Frontier services. There are only three roles that are established here:

• Frontier Administrator
• Core Project Administrator
• User

Frontier Administrator

The Frontier Administrator will have maximum permissions over the FMC. They will have supervision over the entire organization FMC and all of its projects with their workload clusters. The main (original) Frontier Administrator will have the capability to promote/demote other users to/from the Frontier Administration role. Assigned Frontier Administrators can help assist all tasks at an extreme supervision level within Frontier Services using the client-side applications. The main Frontier Administrator should be the only user who has access to the FMC’s kubeconfig as they will be setting all configurations required to release and install Frontier services for the rest of their organization.

All Frontier Administrators have the responsibility of creating new users into their Frontier services. Frontier Administrators are the only users who can delete existing users from the organization; however, appointed Frontier Administrators do not possess the permissions to delete/demote other Frontier Administrators. The only Frontier Administrator who are given these actions will be the main (original). All Frontier Administrators will also be able to promote certain users to the Core Project Administrator role.

Core Project Administrator

This role is designed for specific users granted the capability of creating new projects within the organization. The projects they create, they will be main project administrator for. They will not be able to access projects other core project administrators created unless receiving a member invitation and being assigned a proper role. This role does not guarantee them being a project administrator within that project.

User

This will be the standard role assigned for all those who do not possess either the Frontier Administration role or the Core Project Administration role. They will not be able to perform any actions unless they are invited to join projects and each of their respective clusters. They can still be assigned administration roles within each of these projects and clusters, but they will not have the capability to create new projects or perform super administrative actions throughout the FMC.

Project Level Authorization

The Project Level is the child level of the FMC to stage all projects within the organization’s Frontier services. There are only three roles that are established here:

• Project Administrator
• Core Cluster Administrator
• User

Project Administrator

The project administrator will have maximum permissions over their projects within the FMC. The main project administrator can invite new members into their project that range from the pool of FKP users there are within the FMC. They can not invite Frontier Administrators since they already have super administration privileges. Once new members have been invited, the main project administrator can promote users to either become project or core cluster administrators.

Appointed project administrators will not have authorized actions to promote/demote or remove current members that also have the project administration role. With that being said, all project administrators will be able to effectively manage all workload clusters within their respective project teams.

Core Cluster Administrator

This role is designed for specific users granted the capability of creating new clusters within each project. The clusters they create, they will be main cluster administrator for. They will not be able to access clusters other core cluster administrators created unless receiving a member invitation and being assigned a proper role. This role does not guarantee them being a cluster administrator within that cluster of that project.

User

This will be the standard role assigned for all those within a project level workspace who do not possess either the project or core cluster administration role. They will not be able to perform any actions unless they are invited to join clusters within their assigned project. They can still be assigned administration roles within each of project’s clusters, but they will not have the capability to create new clusters or perform administrative actions in their respective projects.

Cluster Level Authorization

The Cluster Level is the child level of the each project of the organization’s Frontier services to stage all workload clusters. There are only two roles that are established here:

• Cluster Administrator
• User

Cluster Administrator

The cluster administrator will have maximum permissions over their clusters within each project of the FMC. The main cluster administrator can invite new members into their cluster that range from the pool of assigned project members. They can not invite Frontier or project administrators since they already have privileges that are greater than the cluster administrator. Once new members have been invited, the main cluster administrator can promote users to either become cluster administrators as well.

Appointed cluster administrators will not have authorized actions to promote/demote or remove current members that also have the cluster administration role. With that being said, all cluster administrators will be able to effectively manage their assigned workload clusters and its users.

User

This will be the standard role assigned for all those within a cluster level workspace who do not possess an administration role. They will be able to perform the minimum level of authorized actions inside of a workload cluster. These configurations of how far their actions extend will be set in each of their workload cluster’s kubeconfig files given by their cluster administrator.