Salto for
Okta
Articles
SHARE
Gil Hoffer
March 21, 2024
10
min read
At first glance, Salto and Terraform appear to be similar solutions for managing Okta configuration — both aim to streamline operations and ensure consistency. However, a deeper look reveals fundamental differences in their approaches and core strengths.
In this article, we explore those differences and main considerations when choosing between Salto and the Terraform Okta provider for managing your configuration.
Terraform by HashiCorp is an infrastructure-as-code tool that allows teams to define and provision infrastructure using a high-level declarative configuration language called HCL. It enables developers and infrastructure teams to automate the deployment, management, and scaling of various cloud services, helping organizations maintain a consistent workflow across multiple providers and multiple environments. Terraform, with its focus on infrastructure as code, plays a crucial role in DevOps practices by streamlining the deployment process and fostering collaboration among development and operations teams.
Terraform has many providers, including one for Okta, enabling it to manage Okta configuration as code.
Salto is a DevOps platform for managing the configuration of SaaS applications. It translates configurations into a high-level declarative configuration language called NaCl (a dialect of HCL). Salto allows administrators and developers to streamline configuration change management using DevOps processes and tools such as version control, automation, CI/CD, and backup.
Salto supports various IT and business applications, including Salesforce, Jira, NetSuite, Zendesk, and Okta.
With Terraform, those configuration changes would be manually codified (once + variable definitions if needed), committed to Git (using a chosen branching strategy), and deployed to the target environments using the Terraform CLI, potentially from a CI/CD pipeline. This assumes that you already have an up-to-date accurate representation of your environments in HCL and that all of your environments are identical from a configuration standpoint.
If you want to see how Salto works in more detail, check out this video:
As you can see, Salto and Terraform require a very different set of skills.
Effective use of Terraform requires deep knowledge of the tool, typically found within DevOps/Infrastructure teams that manage your AWS, GCP, or Azure configurations. Changes are coded directly in HCL and follow standard development practices. To leverage Terraform for Okta configuration management, your team members will need to be experts in these three areas:
To develop a configuration change, one will need to intimately know the representation of that change in HCL and how to mimic in HCL different operations that they would typically perform in the Okta Admin Console.
For example, this is a sample HCL file for a SAML App (source):
If your team has expertise in all of those areas and can comfortably develop configuration changes manually as code, then Terraform might be a great fit.
While Salto relies on a code-based representation of your configuration, it doesn’t require administrators to be proficient in that representation or to be able to modify it as code. If your IAM team has Okta expertise without a deep understanding of Terraform and infrastructure automation, Salto would be a better fit.
One of Terraform’s assumptions is that changes are always done using code and never directly in the service itself. This assumption makes perfect sense when managing your infrastructure provider (such as AWS), but things become tricky when you need to manage a rich no/low-code UI-based solution like Okta. It's common for a team to have changes done in the service itself when some team members are Okta experts who are more comfortable working with the Okta UI rather than in code (as mentioned above). Another case is if changes (hotfixes) done directly in production. While changes normally shouldn’t be done directly in production, there are some cases where it makes sense.
With Terraform, a direct service change would create a discrepancy between the Terraform state file and the real state of the service—and would require careful specific handling. These changes may be discovered right before an attempt to deploy a change and can cause significant delays.
With Salto, such changes will be detected automatically. Detected changes in lower environments are funneling into the same release pipeline as changes done through code editing, in a streamlined manner. When changes are detected in production, the user can decide whether they should be reverted or accepted (and back-promoted to lower environments).
Terraform deployment mode is simple and follows a standard development process: develop the code and deploy it (so it’s always “source driven”).
Salto supports multiple deployment modes:
While this post is focused on Okta, it’s worth mentioning that both solutions support many other applications.
Terraform has thousands of providers and is typically focused on infrastructure solutions such as AWS, GCP, and Azure. Salto supports multiple applications as well, with a focus on IT and business applications (Jira, Salesforce, Zendesk, Okta, Google Workspace, NetSuite, and more).
One thing to consider here is if your Okta implementation needs to be synergetic with other enterprise applications you’re using.
Terraform is great if you are comfortable working in a CLI, and potentially in an IDE. There are also commercial offerings such as Terraform Cloud, Env0, and Spacelift that add a UI to orchestrate changes already done in code.
Salto can be used from a CLI and also has a powerful web-based UI that enables your team to:
Terraform is licensed under the Business Source License and has various commercial SaaS offerings on top that provide a managed service (such as Terraform Cloud, Env0, Spacelift, etc.)
Salto is based on an open-source project (licensed under Apache 2.0 license). Salto’s SaaS offering has two tiers: a free-for-life tier for configuration visibility and a commercial tier that enables deployments, configuration backup, monitoring, and many more features.
To summarize this comparison, choosing between Salto and Terraform for managing your Okta configuration largely depends on your team's technical expertise and the flexibility you need in your change management process. By considering the strengths and limitations of each tool, you can make an informed decision that best suits your operational requirements and strategic goals.
Salto for
Okta
SHARE
Gil Hoffer
March 21, 2024
10
min read
At first glance, Salto and Terraform appear to be similar solutions for managing Okta configuration — both aim to streamline operations and ensure consistency. However, a deeper look reveals fundamental differences in their approaches and core strengths.
In this article, we explore those differences and main considerations when choosing between Salto and the Terraform Okta provider for managing your configuration.
Terraform by HashiCorp is an infrastructure-as-code tool that allows teams to define and provision infrastructure using a high-level declarative configuration language called HCL. It enables developers and infrastructure teams to automate the deployment, management, and scaling of various cloud services, helping organizations maintain a consistent workflow across multiple providers and multiple environments. Terraform, with its focus on infrastructure as code, plays a crucial role in DevOps practices by streamlining the deployment process and fostering collaboration among development and operations teams.
Terraform has many providers, including one for Okta, enabling it to manage Okta configuration as code.
Salto is a DevOps platform for managing the configuration of SaaS applications. It translates configurations into a high-level declarative configuration language called NaCl (a dialect of HCL). Salto allows administrators and developers to streamline configuration change management using DevOps processes and tools such as version control, automation, CI/CD, and backup.
Salto supports various IT and business applications, including Salesforce, Jira, NetSuite, Zendesk, and Okta.
With Terraform, those configuration changes would be manually codified (once + variable definitions if needed), committed to Git (using a chosen branching strategy), and deployed to the target environments using the Terraform CLI, potentially from a CI/CD pipeline. This assumes that you already have an up-to-date accurate representation of your environments in HCL and that all of your environments are identical from a configuration standpoint.
If you want to see how Salto works in more detail, check out this video:
As you can see, Salto and Terraform require a very different set of skills.
Effective use of Terraform requires deep knowledge of the tool, typically found within DevOps/Infrastructure teams that manage your AWS, GCP, or Azure configurations. Changes are coded directly in HCL and follow standard development practices. To leverage Terraform for Okta configuration management, your team members will need to be experts in these three areas:
To develop a configuration change, one will need to intimately know the representation of that change in HCL and how to mimic in HCL different operations that they would typically perform in the Okta Admin Console.
For example, this is a sample HCL file for a SAML App (source):
If your team has expertise in all of those areas and can comfortably develop configuration changes manually as code, then Terraform might be a great fit.
While Salto relies on a code-based representation of your configuration, it doesn’t require administrators to be proficient in that representation or to be able to modify it as code. If your IAM team has Okta expertise without a deep understanding of Terraform and infrastructure automation, Salto would be a better fit.
One of Terraform’s assumptions is that changes are always done using code and never directly in the service itself. This assumption makes perfect sense when managing your infrastructure provider (such as AWS), but things become tricky when you need to manage a rich no/low-code UI-based solution like Okta. It's common for a team to have changes done in the service itself when some team members are Okta experts who are more comfortable working with the Okta UI rather than in code (as mentioned above). Another case is if changes (hotfixes) done directly in production. While changes normally shouldn’t be done directly in production, there are some cases where it makes sense.
With Terraform, a direct service change would create a discrepancy between the Terraform state file and the real state of the service—and would require careful specific handling. These changes may be discovered right before an attempt to deploy a change and can cause significant delays.
With Salto, such changes will be detected automatically. Detected changes in lower environments are funneling into the same release pipeline as changes done through code editing, in a streamlined manner. When changes are detected in production, the user can decide whether they should be reverted or accepted (and back-promoted to lower environments).
Terraform deployment mode is simple and follows a standard development process: develop the code and deploy it (so it’s always “source driven”).
Salto supports multiple deployment modes:
While this post is focused on Okta, it’s worth mentioning that both solutions support many other applications.
Terraform has thousands of providers and is typically focused on infrastructure solutions such as AWS, GCP, and Azure. Salto supports multiple applications as well, with a focus on IT and business applications (Jira, Salesforce, Zendesk, Okta, Google Workspace, NetSuite, and more).
One thing to consider here is if your Okta implementation needs to be synergetic with other enterprise applications you’re using.
Terraform is great if you are comfortable working in a CLI, and potentially in an IDE. There are also commercial offerings such as Terraform Cloud, Env0, and Spacelift that add a UI to orchestrate changes already done in code.
Salto can be used from a CLI and also has a powerful web-based UI that enables your team to:
Terraform is licensed under the Business Source License and has various commercial SaaS offerings on top that provide a managed service (such as Terraform Cloud, Env0, Spacelift, etc.)
Salto is based on an open-source project (licensed under Apache 2.0 license). Salto’s SaaS offering has two tiers: a free-for-life tier for configuration visibility and a commercial tier that enables deployments, configuration backup, monitoring, and many more features.
To summarize this comparison, choosing between Salto and Terraform for managing your Okta configuration largely depends on your team's technical expertise and the flexibility you need in your change management process. By considering the strengths and limitations of each tool, you can make an informed decision that best suits your operational requirements and strategic goals.