With the growing importance of DevOps roles in technological companies, bringing closer together development teams and operation teams, deployments are more frequent. As a result, possible security holes appear more often. The need to improve the “security at speed” in the context of these workflows created the need of DevSecOps, i.e., best practices to empower the security of the code. SODALITE is all about DevOps, managing remote resources with key users making data privacy a priority. The management of remote resources incorporates security, using well established and robust technology. Let us tell you how we do it!
The SODALITE stack provides tools and methods to authenticate and authorize actions on API endpoints using open-source Identity management and Secure Secret handling tools. Why is authorization required? A single SODALITE endpoint can manage multiple infrastructures belonging to different domains. In addition to proper authentication and authorization of user actions, safe secret management across the whole deployment pipeline is also required and ensured by SODALITE.
From the user’s perspective, any orchestration or automation tool that uses any kind of credentials, access tokens or keys to access and configure resources is considered a risk. The risk of exposing these credentials can be an overwhelming factor for not using a specific orchestration or automation tool. SODALITE addresses the complex issues of creating a secure workflow in an orchestrated automation context by using industry standard open source tools to handle the following three security aspects of complex orchestration: user authentication, user authorization and secret management. The first two points are usually covered by Identity and Access Management (IAM) tools that connect the user identity with system access credentials (authentication) and user rights regarding the usage of specific system resources (authorization). To enable a seamless integration the OAuth 2.0[1] authorization framework was chosen, which is the de-facto industry standard for authorization.
SODALITE uses Keycloak[2] as the IAM provider, a popular and widely used open source tool which simplifies the creation of secure services with minimal coding overhead for authentication and authorization. Keycloak allows a wide customization of options regarding authentication schemas such as two-factor authentication and seamless integration with third-party identity providers like Google or GitHub, making it an ideal tool for extending the reach of the project providing different levels of access to different SODALITE components and different users.
A JSON Web Token (JWT), once issued by Keycloak, is then used across the whole SODALITE workflow. Keycloak allows the creation of various clients for different components, e.g., one set of rules can be applied to users logins from the SODALITE IDE and others for automation components like SODALITE’s Deployment Refactorer. Each client has a client secret assigned that is provided to Keycloak upon token creation to validate Token Endpoint API calls. Once a JWT Token is issued, it can be validated by Keycloak using two standard mechanisms: the introspection endpoint and JSON Web Key Sets. Introspection mechanism provides a more secure way for validating tokens as the token can be revoked before expiration and should be used as default.
In SODALITE, multiple users may cooperate on the same application deployment project for modelling specific Resource Models (RMs) and Abstract Application Deployment Models (AADMs) in the IDE. These models can be private or public, and are usually referred to as different Project Domains, meaning that only a certain group of end users should be granted read or write access to these resources. To ensure this access granularity, client roles and groups are used in Keycloak. Each role provides read or write access to a certain project domain. One user can belong to many Project Domains and thus have any number of client roles assigned, for an effective user and group management without any other separate component needed.
In addition to properly authorising user actions, the third security aspect, Secret Management has been introduced in SODALITE for proper handling of infrastructure secrets such as RSA keys, tokens, logins and passwords . Secret Management has in itself two aspects of handling secret data: security of data in use and security of data at rest. First one is addressed by properly handling the secrets across the whole pipeline: not storing unencrypted information, no logging for security critical parts, and proper user management on virtual containers that host SODALITE components. While SODALITE allows not storing any secrets at all and providing them in inputs, storing secrets in a vault allows to automate workflow and additionally ensure its safety. For that purpose Hashicorp Vault[3] has been chosen, which is a widely used open source tool for secret management. This approach allows SODALITE operators to integrate with their own Vault installations that might not be a part of SODALITE component stack.
