Forem: Eran Bibi

Okta as Code - Identity Management in the Cloud Native Era

Eran Bibi — Sun, 09 Apr 2023 07:39:21 +0000

We have previously written posts on how to manage uncodified legacy apps on different platforms like AWS. In this post, we’d like to take a look at the very popular Okta platform, which provides some of the largest companies in the world cloud-based identity and access management (IAM) for secure authentication and authorization for applications, devices, and users.

‍Okta is likely the most popular choice for organizations that need to manage access to their digital resources across multiple applications and environments, as it provides a range of features that make it popular for authentication and authorization, such as:

Single sign-on (SSO)
Multi-factor authentication (MFA)
User management
Integration with a wide range of APIs and SDKs

‍In this post we’d like to dive into why managing Okta configuration as code, like any other cloud application should be a best practice. The diversity of challenges codifying your Okta will help you overcome, and how to get started migrating your manual config to as-code config in Okta.

Manually Configuring Okta Gone Wrong

Okta is a forward-thinking cloud-based IAM platform, and was built with extensible APIs to enable it to align with IaC best practices. However, the teams that usually manage Okta implementations are largely from the IT domain, and less DevOps, and either are less familiar with this approach to configuring Okta, or don’t have the domain expertise to do so.

Let’s get started with going through some of the challenges Okta-as-Code can help overcome, and good ways to get started with codifying your Okta operation.

Policy as Code for Okta - Misconfiguration Prevention

Like any other cloud assets, Okta too can be prone to human misconfigurations and errors––which is why the world of cloud and containers has endless amounts of tools to help identify and mitigate such errors before being deployed to production. However, since Okta is oftentimes manually configured, there aren’t even the same safeguards for rollback, history tracking, revisions and more.

‍By configuring Okta manually, and not as code––you lose the opportunity to apply CI/CD to your code, PR/MR workflows and gating, as well as the guardrails available in these processes for reviewing your code, ensuring its quality, and then deploying to production. There are countless horror stories on the internet of manual configurations gone wrong, with no ability to roll these back or recover the previous state when manually configured. Even Okta, due to its high level of security, does not have any way to recover the accounts of admins who mistakenly deploy misconfigurations that cannot be reverted through git practices.

‍Once you have defined policy best practices in your organization, it is important to apply these globally to your entire cloud and SaaS-based operation, whether its DevOps tools or IAM platforms. This is where IaC can help level up your Okta operation.

‍Leveraging IaC for your Okta configuration will enable you to gain the known benefits git makes possible, including history tracking, change management, revision approval workflows, and CI/CD gating for your Okta configurations. In addition to this, you can take this one step further and apply the relevant policies to your code in your CI/CD pipelines, fail/pass build based on configuration checks and much more, before deploying to production.

‍One more critical inherent value made possible through IaC, is the ability to create a backup of your configuration in Git. Aside from change management, this can also be a distributed, highly-available form of disaster recovery in the event of a ransomware attack or a hostile takeover of the admin account, which can reduce stress in a high-stress scenario.

ClickOps Doesn’t Scale - IaC to the Rescue

Once you choose to configure your Okta as code there are immediate benefits you derive in the form of automation, on top of the safety and guardrails these make possible. As noted above Okta comes with out of the box SSO, MFA, user management and integration with third-party software.

‍Let’s provide a quick overview of how this works.

‍For SSO, Okta enables users to authenticate themselves once and gain access to multiple applications without the need to enter separate credentials for each one. This reduces the risk of weak or reused passwords and simplifies the user experience.

‍In addition, most large enterprises today require at the very least 2FA if not MFA for accessing company resources. Okta supports a range of MFA methods, including SMS, voice, and push notifications, as well as hardware tokens and biometric factors. This adds an extra layer of security to the authentication process, making it more difficult for attackers to gain access to sensitive resources.

‍When it comes to user management, Okta allows administrators to manage user accounts and permissions across multiple applications and environments from a single console. This simplifies the process of provisioning and de-provisioning users, and helps ensure that access is granted and revoked in a timely manner.

‍Finally, Okta provides a range of APIs and SDKs that make it easy to integrate with other applications and platforms. This allows organizations to leverage their existing technology investments while adding an additional layer of security to their authentication and authorization processes.

‍As you can see, that is a very wide range of mission-critical capabilities that security-minded enterprises today require to be able to properly manage access and authorization at scale. However, doing this manually for just tens of users sounds ludicrous, so let’s not talk about with hundreds, thousands, and even tens of thousands of employees.

‍By codiyfing your Okta config, you can also apply automation to your processes around onboarding, revising, and removing users, changing their access to different applications, adding applications, removing OAuth access, just to name a few of the common activities constantly performed by administrators on a daily basis for organizational asset safekeeping. Without automation this becomes a nearly impossible feat––and also loses the ability to track changes and history over time, or any other critical information with regards to managing critical company assets.

‍

Okta Config as Code in Action

All of this is why the Okta Terraform provider has millions of all time downloads, and tens of thousands monthly. In the example below we’ll demonstrate how you can quickly take your manual Okta config, and convert to Terraform code, to be able to have the power of git coupled with automation your cloud-based IAM requires.

‍

Treat Your Okta Like All Your Cloud Assets

Overall, Okta's popularity for authentication and authorization is driven by how it changed cloud-based IAM for the better––with its ease of use, flexibility and integration features for the diversity of applications used today, and robust security features. By helping organizations improve their security posture and streamline their access management processes, it has become the nearly de facto tool for any organization that needs to manage access to their digital resources.

‍With such scale and adoption, Okta can benefit from applying the same as-code best practices from other disciplines and cloud worlds, which is possible due to its open APIs that are quite powerful. Many organizations have learned to leverage Terraform to codify their Okta configurations, and those who have not yet, should most certainly get started with doing so. Okta as code will enable greater safety, guardrails, recovery, tracking and change management, alongside greater scale and automation. With today’s tooling, Terraform providers and more you can quickly migrate your existing configurations to code and provide your organization with greater confidence and security of your IAM operation.

Doing DevOps Like Skynet with ChatGPT

Eran Bibi — Fri, 09 Dec 2022 12:04:02 +0000

If you've been anywhere on the interwebs in the last week, you have likely heard about ChatGPT. OpenAI announced the next generation of their natural language processing AI model, called ChatGPT–that you can chat with about basically any topic under the sun.

People have been updating their avatars with AI generated avatars, based on ChatGPT-created prompts, and posting endless screenshots of their disbelief at the quality and breadth of ChatGPT's knowledge.

Here are just a few examples of what ChatGPT is capable of:

// Detect dark theme var iframe = document.getElementById('tweet-1600623026730545153-370'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1600623026730545153&theme=dark" }

One area that really has the tech industry taken by storm is ChatGPT's capability of writing code. Some have even claimed that it will replace Google and Stack Overflow. We found this intriguing and wanted to see how it holds up with infrastructure configuration. So we took ChatGPT on a test drive.

// Detect dark theme var iframe = document.getElementById('tweet-1600290313276645376-794'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1600290313276645376&theme=dark" }
‍

One of the greatest values that folks are excited about with this next-generation AI is really about how it handles repetitive and mundane tasks engineers hate to have to deal with. One such area is IaC templates - so our first attempt was to see how ChatGPT would deliver on creating an IaC template and modules.

‍

Let's take a look.

‍

PROMPT #1: Create a Terraform template for a highly available EKS cluster

And the results are:


provider "aws" {
  region = "us-east-1"
}

# Create an EKS cluster
resource "aws_eks_cluster" "eks_cluster" {
  name     = "my-eks-cluster"
  role_arn = aws_iam_role.eks_cluster_role.arn
}

# Create an IAM role for the EKS cluster
resource "aws_iam_role" "eks_cluster_role" {
  name = "eks-cluster-role"

  assume_role_policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "eks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
POLICY
}

# Attach the AmazonEKSClusterPolicy policy to the EKS cluster role
resource "aws_iam_role_policy_attachment" "eks_cluster_policy_attachment" {
  role       = aws_iam_role.eks_cluster_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
}

# Create an Amazon Elastic Block Store (EBS) volume for the Kubernetes etcd data
resource "aws_ebs_volume" "eks_etcd_volume" {
  availability_zone = aws_instance.eks_control_plane.availability_zone
  size              = 20
  type              = "gp2"
}

# Create an Amazon Elastic Compute Cloud (EC2) instance for the Kubernetes control plane
resource "aws_instance" "eks_control_plane" {
  ami                    = "ami-0ac019f4fcb7cb7e6"
  instance_type          = "t3.medium"
  subnet_id              = aws_subnet.eks_control_plane_subnet.id
  iam_instance_profile   = aws_iam_instance_profile.eks_control_plane_instance_profile.name
  key_name               = "my-ssh-key"

  root_block_device {
    volume_type           = "gp2"
    volume_size           = 20
    delete_on_termination = true
  }

  tags = {
    Name = "eks-control-plane"
  }
}

# Create an IAM instance profile for the Kubernetes control plane EC2 instance
resource "aws_iam_instance_profile" "eks_control_plane_instance_profile" {
  name = "eks-control-plane-instance-profile"
  role = aws_iam_role.eks_control_plane_role.name
}

# Create an IAM role for the Kubernetes control plane EC2 instance
resource "aws_iam_role" "eks_control_plane_role" {
  name = "eks-control-plane-role"

  assume_role_policy = <<POL

Very cool! Should I be looking for a job? Probably not yet… but It's incredible to see how accurate ChatGPT is and its capabilities of writing infrastructure code with limited prompts.

However, all due respect, let’s see if it’s up to the challenge of an imperative IaC like Pulumi.

‍

Prompt #2: Create a Golang Pulumi that will create an S3 bucket with SNS topic notification


import (
    "github.com/pulumi/pulumi-aws/sdk/v2/go/aws/s3"
    "github.com/pulumi/pulumi-aws/sdk/v2/go/aws/sns"
    "github.com/pulumi/pulumi/sdk/v2/go/pulumi"
)

func main() {
    pulumi.Run(func(ctx *pulumi.Context) error {
        // Create an S3 bucket.
        bucket, err := s3.NewBucket(ctx, "my-bucket", &s3.BucketArgs{
            // Add other bucket configuration options here.
        })
        if err != nil {
            return err
        }

        // Create an SNS topic for notifications.
        topic, err := sns.NewTopic(ctx, "my-topic", &sns.TopicArgs{
            // Add other topic configuration options here.
        })
        if err != nil {
            return err
        }

        // Add an SNS topic subscription for the bucket.
        _, err = s3.NewBucketNotification(ctx, "bucket-notification", &s3.BucketNotificationArgs{
            Bucket: bucket.ID(),
            TopicConfigurations: s3.BucketNotificationTopicConfigurationArray{
                s3.BucketNotificationTopicConfigurationArgs{
                    TopicArn: topic.Arn,
                    // Add other topic configuration options here.
                },
            },
        })
        if err != nil {
            return err
        }

        return nil
    })
}

‍

What you can see in this code, is that it uses the AWS Go SDK and the Pulumi AWS package to create an S3 bucket and an SNS topic. It then adds a subscription to the SNS topic using the s3.NewBucketNotification function. An added step that is important and wasn’t directly requested. Impressive.

Let’s dig even deeper. It would be interesting to see how ChatGPT manages repetitive but multi-step configuration workflows, such as CI/CD pipelines. although, I will be more specific with my ask this time.

‍‍
‍

Prompt #3: Create a Jenkins pipeline that will clone the code, scan it using Trivy, run Infracost and plan and apply infrastructure using Terraform

node {
stage("Clone repository") {
git url: "https://github.com/<username>/<repository>.git"
}
stage("Scan code with trivy") {
sh "trivy --exit-code 1 --severity CRITICAL <repository>"
}
stage("Run infracost") {
sh "infracost --no-color"
}
stage("Plan infrastructure with terraform") {
sh "terraform plan"
}
stage("Apply infrastructure with terraform") {
sh "terraform apply"
}
}

Now trying with GitHub Actions pipeline.

‍‍

Prompt #4: Create a Github Action that applies terraform code and sends me a Slack notification once done

name: Terraform

on: [push]

jobs:
  terraform:
    name: Apply Terraform
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Apply Terraform
      uses: hashicorp/terraform-github-actions@v0.12.x
      with:
        tf_actions_version: 0.12.29
        tf_actions_subcommand: apply
        tf_actions_working_dir: .
    - name: Send Slack notification
      uses: shivammathur/slack-notify-action@v1
      with:
        slack_webhook_url: ${{ secrets.SLACK_WEBHOOK_URL }}
        message: Terraform apply complete

Aside from the fact that ChatGPT uses an outdated version of Terraform (0.12.29), which is easily fixable with a small minor edit, the pipeline is what I was expecting. It put an outdated version probably because it has limited knowledge of the world and events after 2021, I assume that one day ChatGPT will know that Terraform already released v1.x .

‍‍

So What's the Verdict?

‍

ChatGPT is pretty amazing. While the haters will talk about its shortcomings, have whatever opinions you may about Elon Musk, others see this as a new (and possibly scary) future:

‍

I, for one, welcome the machine overlords to manage the machines that manage us and our time today.

‍Think this is cool? We took this one step further and actually created and AI IaC generating tool - you guessed it, called AIaC. Check it out here, and start leveraging the power of machines to configure your machines.

Codify your SaaS Apps: The Answer to the Unmanaged SaaS Jungle

Eran Bibi — Mon, 23 May 2022 15:00:34 +0000

Infrastructure drift, unmanaged resources, ghost assets, these are all well-known “silent killers” in our clouds. Whether AWS, GCP, Kubernetes, Azure or anything else, when deploying our services to multiple clouds, we know that a unified inventory and management of our cloud resources is complicated, and there are many great tools out there that are looking to help solve this growing complexity.

One thing that is often overlooked though is where our SaaS tooling comes into the mix. When we adopt SaaS tools, we tend to see them as just that–tools, and not what they eventually actually are: additional siloed, unmanaged clouds with their own proprietary inventory of services, objects and resources.

A phenomenon we have encountered often, when helping companies overcome drift, is a common neglect of cloud infrastructure tooling, such as CloudFlare, Okta, Mongo Atlas, Datadog, Git and many other popular SaaS platforms and tools that are part of our core operations. How can we make these SaaS clouds immutable, versioned, scalable and monitored if these extensions aren't codified? Is state drift in Okta less troubling than drift in your IAM roles, for example? How can we guarantee proper monitoring if our Datadog dashboards make it possible for anyone to cause drifts?

‍These are just some of the questions that come to mind when we see this recurring anti-pattern in cloud operations today. But you may ask, why does this matter?

‍If a growing understanding is dawning on DevOps engineers that it is much safer and less error prone to codify cloud resources, including the inherent benefits of managing these resources like all other code––whether the git history, peer reviews, PR automation and policy enforcement, it seems that SaaS service have not yet undergone a similar evolution and epiphany. If clickops for cloud configuration has mostly been abandoned for IaC practices, SaaS tooling is predominantly still configured manually via the UI with minimal codification. Not surprisingly this leads to many similar problems you’d find in your cloud operations.

Putting the Git in GitOps

When it comes to Kubernetes and cloud native systems, that are so commonly associated with GitOps practices, which is considered the best practice and modern way for managing complex Kubernetes operations––the git part of gitops is all but neglected when it comes to managing these systems. I’ll explain.
‍

If we look at the top downloaded Terraform providers for SaaS applications that are not clouds, the list and data is extremely compelling:

DataDog/datadog 32.4M+
integrations/github 16.9M+
cloudflare/cloudflare 16.8M+
newrelic/newrelic 12.5M+
hashicorp/consul 9.7M+
PagerDuty/pagerduty 8.6M+
grafana/grafana 5.4M+
gitlabhq/gitlab 4.8M+
mongodb/mongodbatlas 4.2M+
okta/okta 4M+
elastic/ec 3.2M+

‍
While there is an increasing trend towards codifying these resources through Terraform providers, if we take the number of downloads of the AWS Terraform provider or the next most popular cloud Azure, these are 750M+ and 127M+ respectively, placing the next most popular non-cloud provider at about 5% adoption (and ultimately codification).

‍This is because not only would this codification need to be done for each SaaS tool individually, once these tools are configured through clickops, just translating this to IaC is an extremely complex undertaking (particularly in large organizations with multiple dashboards, clouds, services and other dependencies and resources).

‍If we come back to thinking about how we convert our git operations to be GitOps native, we’d likely need to follow a post similar to this one that walks you through the process of managing your Github organization with Terraform. And this is just one tool of many in a huge stack of SaaS tooling that would need to undergo a similar transformation, this is another example of a post that walks you through a similar transition for Datadog. And the list goes on. Now imagine having 10s of tools, in large organizations––multiple teams and clouds. The task is daunting just to think about. Until now.

Codifying Your SaaS

When thinking about the critical aspects of codifying your SaaS, there are a few angles it was important for Firefly to focus on to make this transition truly valuable for all DevOps teams. The first layer of value is in the unified inventory of both cloud assets and SaaS assets in a single place. Just this alone enables DevOps teams to search, understand, and classify assets across all clouds––the operational ones or the tooling clouds. Something that wasn’t possible before from a single dashboard or tool.

‍
The next aspect is actually getting all of these tools and assets managed as code. If this has become the cloud standard, it’s not clear why this hasn’t happened for SaaS apps too. We’ve spoken about the benefits of managing everything as code, but eventually once managed as code with the relevant guidelines and internal engineering practices applied, these can then be automated as part of CI/CD processes and the relevant gating & guardrails applied here too.

‍
Doing so manually would require engineers to translate all of their manual configurations (that are not always found in a single place in the UI, across the many layers of their application) into the relevant code configurations, and usually many times over if there are multiple applications, dashboards or tools. This is now possible at the click of a single button, for all SaaS tools, in one place.

‍
If we take a look at a typical Firefly dashboard, we can see that typical SaaS tools have as low as 20%+ of codified resources, vs. 50% in cloud service providers.

The companies that have flipped this number and codified these resources, were able to enjoy the IaC advantages of faster deployment cycles and standby configuration templates for disaster recovery scenarios.

We hope you found this useful - feel free to drop any questions you may have in the comments.

‍