What is Role Based Access Control and why is it needed anyways?
Role-based access control (RBAC), is a mechanism that creates guardrails by restricting system access. In the context of CI/CD RBAC helps in separation of duties by defining user roles and actions of specific CI/CD or DevOps tools, applications and other services or resources.
RBAC ensures authorized and intended access to the resources to avoid risks and enhance security. In short RBAC helps enterprises with:
- Improved security,
- Decreased security risk and breaches around sensitive data,
- Reduced cost,
- Complete visibility into who’s doing what,
- Enabling audit readiness.
There are ways to implement RBAC in Spinnaker and this post provides insights into how this can be achieved in general and also for enterprises who intend to implement RBAC for a continuously growing / scaling model.
A quick disclaimer, The exact process depends on the specific version and configuration of Spinnaker you are using. Refer to the Spinnaker documentation or consult with your Spinnaker administrator for the details.
In general, one may follow the below mentioned steps to implement Role-Based Access Control (RBAC) in Spinnaker for secure delivery:
Identify Users and Define Roles
Identify the different roles or personas within your enterprise requiring access to Spinnaker. For example, roles like “Admin,” “Developer,” and “Viewer.” Determine the specific permissions and actions associated with each role.
Understand your organization’s requirements: Understand and determine the roles and permissions that are needed for different users or groups at different levels within your organization.
Identify built-in roles
Spinnaker comes with some built-in roles that you can use as a starting point. These roles include ADMIN, READ_ONLY, OPERATOR, DEPLOY, and READ_WRITE. All permissions in Spinnaker are granted to a role including super admin.
Create custom roles
If the built-in roles don’t meet the specific requirements, you can create custom roles with required permissions specific to your needs. This requires specific edits in the configuration files in your Spinnaker installation. You can use different alternative mechanisms to define and associate roles with a user. You can use either Yaml file or Github teams or google groups, LDAP or a SAML group.
Determine the specific permissions that each role should have. Permissions control what actions a user can perform within Spinnaker. Some common permissions include creating applications, deploying pipelines, managing infrastructure, and accessing certain resources.
Assign roles to users or groups
Once you have defined the roles and permissions, you can assign them to individual users or groups. Users can be assigned multiple roles if necessary.
You may also want to refer to Configuring groups from a file in Spinnaker with restricted permissions for cloud services
Test and iterate
Test the roles and permissions to ensure they provide the desired access levels and restrictions. Make adjustments as needed based on feedback from users or any additional requirements that arise.
Maintain and review roles
Regularly review and update the roles and permissions as your organization’s needs evolve. This ensures that users have appropriate access and helps maintain the security and integrity of your Spinnaker deployment.
Configure Spinnaker User Accounts
Set up user accounts or integration accounts within Spinnaker. These accounts will be associated with the individuals or systems that will interact with Spinnaker.
Setting up user accounts in Spinnaker involves integrating Spinnaker with an identity provider (IdP) and configuring user authentication. Here’s a general process for setting up user accounts in Spinnaker:
Choose an identity provider (IdP)
Select an IdP that will handle the authentication and authorization of users in Spinnaker. Some popular IdPs include Okta, Google Identity Platform, Azure Active Directory, and Auth0.
Configure the IdP
Follow the documentation provided by your chosen IdP to set up the necessary configurations. This typically involves creating an application or client within the IdP and obtaining client IDs, client secrets, and redirect URLs.
In case, you may want to refer to SAML Authentication to Spinnaker using Jump cloud as the identity provider.
Access the Spinnaker configuration
Access the Spinnaker configuration files or the Spinnaker web UI. The location or method for accessing the configuration depends on your Spinnaker deployment.
Configure authentication in Spinnaker
If you’re using configuration files, locate the appropriate configuration file(s) for Spinnaker’s authentication settings. The file(s) may vary depending on the Spinnaker version and deployment type. Commonly used files include gate.yml, clouddriver.yml, or spinnaker-local.yml.
You can also refer to the setting up SAML Authentication in Spinnaker using Okta.
Integrate with the IdP
In the configuration file, find the section for authentication settings and configure the integration with your chosen IdP. This typically involves providing the IdP’s details such as URL, client ID, client secret, and redirect URL. Refer to the Spinnaker documentation for the specific configuration details for your IdP.
Save and restart Spinnaker
After adding the authentication details, save the configuration file(s) and restart the Spinnaker services to apply the changes.
Test user authentication
Once Spinnaker restarts, test the user authentication by accessing the Spinnaker web UI. You should be redirected to the IdP’s login page, where you can authenticate with your user credentials. Upon successful authentication, you should be redirected back to the Spinnaker UI.
Define user roles and permissions
After authentication is set up, you can define user roles and permissions in Spinnaker using the Role-Based Access Control (RBAC) system. This allows you to assign appropriate permissions to users based on their roles within the system. Refer to the previous response on how to define user roles in Spinnaker.
Map the roles defined in step 1 to specific permissions within Spinnaker. Permissions control what actions a user can perform within Spinnaker. For example, an admin role might have permissions to create and manage pipelines, while a viewer role might only have read-only access.
Once you have defined the roles and their corresponding permissions, configure them in Spinnaker. The steps may vary depending on the version and installation method you’re using.
Spinnaker 1.21 and above
Starting from version 1.21, Spinnaker has a built-in RBAC system called Fiat. You can define roles and permissions using the Fiat configuration file or through the Spinnaker web interface.
Spinnaker versions prior to 1.21
If you’re using an older version of Spinnaker, you might need to use a different RBAC mechanism such as Kubernetes RBAC or custom authorization providers. Refer to the Spinnaker documentation for instructions specific to your version.
Test and Validate
Verify that the assigned roles and permissions are functioning as expected. Test different user accounts and groups to ensure they have the appropriate level of access and are restricted from performing actions outside of their assigned permissions. This needs to be done manually and obtaining user feedback.
In the below image as we can see the configured groups are visible when we go to the config of a spinnaker application and edit the attributes.
Similarly the next image shows the permissions that can be granted to the respective groups to perform relevant operations:
Regularly Review and Update
RBAC is an ongoing process. Regularly review and update the roles, permissions, and user assignments based on changes in your organization’s requirements and personnel.
How to easily scale security guardrails on Spinnaker using RBAC?
World’s leading enterprises use the hybrid model of Spinnaker (enterprise version of Spinnaker with Addons).
OpsMx ISD for Spinnaker helps you to secure the user access to data, pipelines, infrastructure and deployments. This is facilitated with the help of specific addons for Spinnaker that OpsMx has developed. It basically allows engineers to manage user access and assign permissions to specific components of the end-to-end CI/CD pipelines, for example, DevOps tool chain, cloud infrastructure, policies, security, etc.
A quick glimpse into setting up guardrails for your CI/CD process/ workflow.
Creating User group and assigning permissions
Adding User Roles
Adding Guardrails for Feature Visibility (Feature Flags)
Setting up permissions for Cloud / Target destinations
Setting up user/ group permissions for DevOps tool chain (for example, Jenkins)
These are just a few of many examples of how OpsMx ISD for Spinnaker set up guardrails to secure user access for data, pipeline, infrastructure and deployments. ISD for Spinnaker also allows you to easily get going with production pipelines in minutes and also enable security and compliance checks in a proactive manner.
OpsMx makes Spinnaker secure, scalable, user friendly and enterprise ready.
OpsMx has developed specific addons to help enterprises achieve intelligent automation for approvals, verification, security and compliance while enabling audit-readiness for the enterprises at any given point in time. These addons reside on top of open source or OpsMx enterprise version of Spinnaker to accelerate the software release velocity and deployment speed by 10x while ensuring security.
Contact us to learn more about delivery intelligence using OpsMx ISD for Spinnaker.