22 July 2024

Service Account Privilege Management

Introduction

GigaSpaces already secures user accounts by, for example, using IDP. This is now being expanded to include the securing of service accounts. A Service Account is an account that is typically used by an application or a compute workload. It is an application that wishes to access GigaSpaces resources. This could either be a user of applications or components that wish to access GigaSpaces APIs. A service account differs to a user account in that it is associated with software that runs in our XAP Skyline A highly customizable developer platform that allows building scalable HA with high throughput and ultra-low latency Java applications running on Kubernetes clusters or Smart DIH Smart DIH allows enterprises to develop and deploy digital services in an agile manner, without disturbing core business applications. This is achieved by creating an event-driven, highly performing, efficient and available replica of the data from multiple systems and applications, environments.

The service account has both internal and external applications:

Internal Smart DIH Digital Integration Hub. An application architecture that decouples digital applications from the systems of record, and aggregates operational data into a low-latency data fabric.: A user performs an action, but something needs to happen from that trigger. Each action has their own life cycle and is disconnected from the user who has initialized it all. An example of internal use is data pipeline or data micro-services.
External Applications: An application which wants to read from our XAP GigaSpaces eXtreme Application Platform. Provides a powerful solution for data processing, launching, and running digital services Skyline or Smart DIH environments. For example, a user who wishes to write a Java application to read from them. The application does not necessarily need to be deployed on the same Kubernetes An open-source container orchestration system for automating software deployment, scaling, and management of containerized applications. cluster. A service account needs to be defined for each applications before they can access GigaSpaces API. These applications will all require authentication and authorization capabilities.

An external IDP An identity provider, or IDP, stores and manages users' digital identities. IDP and SSO can work together to authenticate users. cannot be relied upon as it cannot manage services, only users.

GigaSpaces has a mechanism that will manage the service account application types mentioned above.

Authentication Flow

An application is introduced that wants to access the Space Where GigaSpaces data is stored. It is the logical cache that holds data objects in memory and might also hold them in layered in tiering. Data is hosted from multiple SoRs, consolidated as a unified data model., like a PU This is the unit of packaging and deployment in the GigaSpaces Data Grid, and is essentially the main GigaSpaces service. The Processing Unit (PU) itself is typically deployed onto the Service Grid. When a Processing Unit is deployed, a Processing Unit instance is the actual runtime entity.. By default the Space is locked for read/write access.

The application contains a secret (hidden) secret.
As part of the connection process, the application asks the authentication service (part of Kubernetes) if it accepts the secret and then tries to match that secret with an existing secret that it already has stored.
If a match is found the secret is accepted.
If no match is found, the access to the Space is denied.
A JWT JSON Web Token is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON. JWTs are credentials, which can grant access to resources. token is created. The JWT token is used to check for validity and is authenticated. It is temporary and contains an expiration date.
The JWT token is used to authenticate and authorize access to the Space.
The Space checks the JWT token and the roles (for example read/write permission associated to the role).
If the JWT or the role in the JWT are not permitted, the Space will deny access.
If the access is granted, then access to the Space will be granted.

Implementation

Internal Smart DIH: Services that are created from within our XAP Skyline or Smart DIH environments, such as a Pipeline or a Micro-Service, will automatically be registered. A service account will be created for any new service and this will be transparent to the user.
External Applications: There is an interface through which a user can register their application as a service account so GigaSpaces is aware of it.

Once the services are defined, roles can be assigned to them. From then, all the privileges management uses the RBAC Role-based access control (RBAC), also known as role-based security, is a mechanism that restricts system access. It involves setting permissions and privileges to enable access to authorized users. model which replicates what is implemented for user accounts. Due to this, it seamlessly compliments the already available security authorization management.

Authentication APIs

The following authentication APIs are available

API Type	Usage	How Secret is Applied	Result
Proxy	Java apps that require access the Space from a micro-service, PU, etc.	In a file (Kubernetes secret)	Proxy initializes actions limited to the role defined
API	Access APIs	In the URL	JWT created
Data Gateway	Dbeaver, Tableau, PowerBI	ID/secret contained in the credentials	A connection to the Space
V3 Driver	JDBC Java DataBase Connectivity. This is an application programming interface (API) for the Java programming language, which defines how a client may access a database. access	ID/secret contained in the credentials	A connection to the Space

Service Account Secrets

Service account secrets are generated by GigaSpaces automatically. Users cannot generate or provide their own secrets. SpaceDeck GigaSpaces intuitive, streamlined user interface to set up, manage and control their environment. Using SpaceDeck, users can define the tools to bring legacy System of Record (SoR) databases into the in-memory data grid that is the core of the GigaSpaces system. is used to manage the secrets of the Service Accounts. They are certain default Service Accounts that will always be displayed and they are required to run the system. These are predefined in the system.

Connecting to a Space Using an External Java Client

Every Java client requires its own Kubernetes YAML manifest (deployment.yaml). In order to enable for the external Java client to connect to the Space, the following has to be added to the Java client definition:

The Java client definition (YAML) must contain SECURITY_BASE_URL and CLIENT_SECRET_PATH defined as environment variables. The SECURITY_BASE_URL must point to the Security Service. In a standard implementation, this should be set to http://xap-security-service:9000.
The Client Secret file must be present within the service pod and contain the Secret of the corresponding Service Account. To ensure this, a Kubernetes Secret must be created containing the Service Account Client Secret. The Service Account Client Secret is obtained from SpaceDeck for any generated Service Account. In addition, the Client Secret must be mounted as a file on the path provided in the environment variable CLIENT_SECRET_PATH .
Any service needs to use the SpaceProxyConfigure(spaceName).asService (serviceAccount, securityEnabled) when connecting to a Space.

Authorization

Through SpaceDeck, roles can be defined per service accounts. This uses the same mechanism that is employed for user accounts. The Space doesn't differentiate between a user or an application, it just checks the JWT token and authenticates it against the application which has created it. The Space checks the authenticity of the JWT token and receives the claim + role. In terms of authorization, the role is being checked according to the role and privileges contained in it and knows if the requested operations are allowed or not.

Best Practice

It is advised to change the secret if there is a problem with the application or if you think it has been compromised. In this case, the service account can also be revoked, which blocks it. The secret is not typically changed for internal processes (e.g. Pipeline) unless it is suspected that someone is compromising the secret, as this would block everything (e.g. the XAP Manager for performing scale operations, or the creation of Pipelines).
It is important to note that the expiration of the JWT token is not the same as the expiration of the secret. The JWT token can have an expiration time configured for 5 minutes, for example, and this means it can be used even if that service account is revoked. Only after the expiry time, after being revoked (in this example 5 minutes), and a new JWT token is requested will the application not be provided with one. In summary, the post revoke access is not blocked until the JWT token has expired.
Secrets should be rotated. GigaSpaces currently does not have the ability for automatic rotations. This means, users should rotate the secrets manually through SpaceDeck, every half a year with the procedure provided by GigaSpaces. When the secrets in the authentication server are rotated this will necessitate changing all the secrets in the external clients.

How To

Please refer to our SpaceDeck documentation which explains how service accounts,. secrets, roles and privileges are created and managed.