尝试使用Okta × Terraform来管理共享账户

1 年 ago
科, 颖
3 minutes

本文是Bit Key公司2023年IT系统专家日历中的第一天的投稿。

初次见面，我是株式会社比特钥的日浦。我于2019年入职，目前负责比特钥的信息系统工作。我正在努力尝试如何将我在SRE和CRE等服务开发和运维方面的经验应用到企业领域中。

这个问题的前提条件是什么？

在Bitkey内使用Okta进行员工ID管理。虽然其功能繁多且使用起来有些困难，但我们每天都在尝试不同的功能。

考虑访问控制的安全政策时，我认为最大的使用优势是无需依赖SaaS功能，只需在Okta上进行设置即可完成。例如，即使SaaS没有连接来源IP地址限制功能，也可以通过Okta的访问策略进行设置和控制。

然而，当利用IDaaS产品推进ID管理时，确实存在无法使用SaaS的SAML认证。这可能是因为只有在最高级别的Enterprise计划中才能使用，或者根本就不支持SAML认证。

在这种情况下，我们可能会使用“共享账户”来在员工之间共享ID/PW，但是我们会面临管理和操作上的问题。

共享账户的问题

    • ID/PWを「教える」という運用が前提となるため安全性が低い

 

    • 「誰が使えるのか」を正確に管理するのが実質不可能

 

    • SaaS側の機能有無に依存することになる

 

    ex)組織のセキュリティポリシーとして「オフィス外からのアクセス」を禁止している場合など

在这种情况下，您可以使用Okta的Secure Web Authentication（以下简称SWA）来使用符合组织安全策略的安全单点登录（SSO）。

安全网络身份验证（SWA）是什么？

(SWA) shì ?)

简单来说，我们可以通过在Okta上配置SAML认证应用程序，使其像ID/PW认证应用程序一样运行，并且还可以通过Okta的认证实现单点登录。它的使用方式几乎与其他认证方法的应用程序没有太大差异。

    • アプリとして登録できる

 

    • ユーザーやグループがアサインできる

 

    • 認証ポリシーにより、アクセスコントロールが可能

 

    ID/PWをOkta上に登録することで、SaaS上でのユーザーによる入力をスキップできる

 

试试用SWA

下面的博客由Cloud Native先生提供，非常易于理解，其中包含了设置方法和使用指南。

 

如果要具体解释使用Okta进行SSO登录的应用程序的区别，那么在注册时将需要以下工程：

    1. 在浏览器扩展功能中安装 Okta 浏览器插件

 

    1. 在 Okta 管理页面上注册应用时，请注册以下信息：

ID/PW
输入ID密码的HTML选择器
登录按钮的HTML选择器
※ 需要使用开发者工具等确认 SaaS 登录页面。

只需针对所有员工使用Chrome的管理功能或Jamf PRO进行一次设置即可解决1的问题，但针对2的DOM调查需要每次注册应用时都执行。

我們試著使用Terraform將SWA建立為基礎建設。

这样方便至极的SWA，可惜像我这样懒散的情报系统工作人员，有时会感到从屏幕上点击注册的工作很辛苦。
确认注册状态也很繁琐，而其他人在管理界面参考现有的SWA应用并模仿注册也很困难，所以为了增加可再现性，让我们通过源代码进行管理吧。

建议您首先照着以下文章将Okta与Terraform进行配置管理，这篇文章非常有参考价值。

 

下面是一个名称为Sample App的虚构SaaS的SWA登录示例。

源代码

首先定义okta_app_shared_credentials。

resource "okta_app_shared_credentials" "sample_app" {
  label           = "Sample App" // 任意の名前
  status          = "ACTIVE"
  username_field  = "#email"    // ID入力部分のセレクタ
  password_field  = "#password" // PW入力部分のセレクタ
  button_field    = "#button"   // ログインボタン入力部分のセレクタ
  shared_username = "example@example.com" // ログインID
  shared_password = var.PW_SAMPLE_APP // パスワード
  url             = "https://example.com/" // ログインページのURL
  logo            = "../terraform/assets/example.png"
  admin_note      = "created by terraform. サンプルアプリだよ"
}

接下来，我们将定义Okta组以及组规则，来确定可以使用这个SaaS的人员。
在Bitkey中，原则上不直接为应用分配人员或组，而是创建一个名为“App_Assign_hogehoge”的分配组。

resource "okta_group" "App_Assign_sample_app" {
  name        = "App_Assign_sample_app"
  description = "created by terraform"
}

resource "okta_app_group_assignments" "App_Assign_sample_app" {
  app_id = okta_app_shared_credentials.sample_app.id
  group {
    id       = okta_group.App_Assign_sample_app.id
    priority = 1
  }
}

resource "okta_group_rule" "App_Assign_sample_app" {
  name   = "App_Assign_sample_app"
  status = "ACTIVE"
  group_assignments = [
    "${okta_group.App_Assign_sample_app.id}"
  ]
  expression_type = "urn:okta:expression:1.0"
  expression_value = join("", [
    "isMemberOfAnyGroup(",
    "\"${okta_group.team-corporate-engineering.id}\"",
    ")"
  ])
}

创建一个名为”App_Assign_sample_app”的组，并使用”okta_app_group_assignments”将该组分配给”Sample App”。
同时，创建”okta_group_rule”以指定默认分配给可以通过SSO访问”Sample App”的组。

在Bitkey中，人們經常使用「根據組織圖創建的群組」或者「通過Okta Access Request分配的群組」。

最终，我们将PW定义为一个变量，以便登录到Sample App中。

variable "PW_SAMPLE_APP" {
  sensitive = true
}

在源代码上直接写密码是可能的，但我们应该避免将凭据信息写进源代码中。
然而，根据Terraform的规范，状态是被记录在state中的，所以我们应该执行以下操作。

ローカルには保存せず、AWS S3などに保存し、そちらのアクセス管理を徹底する

.gitignoreに記述しておく

.tfstate
.tfstate.

可能在以后还会写一篇关于使用Okta进行AWS访问管理的文章。

此外，通过指定sesitive = true，也可以在输出的plan和apply中进行脱敏处理，以及在CI/CD的执行环境中不显示输出。

以下是GitHub Actions的示例代码，详细内容略。

name: terraform-plan

on:
  pull_request:
    paths:
      - ".github/workflows/tf-plan.yml"
      - "terraform/**"
  workflow_dispatch:

env:
  TF_VAR_OKTA_API_TOKEN: ${{ secrets.OKTA_API_TOKEN }}
  AWS_ROLE_ARN: ${{ secrets.AWS_ROLE_ARN }}
  AWS_DEFAULT_REGION: ap-northeast-1
  TF_VAR_PW_SAMPLE_APP: ${{ secrets.PW_SAMPLE_APP }}

jobs:
  terraform-plan:
    name: Terraform plan
    runs-on:  ubuntu-latest
    timeout-minutes: 5
    permissions:
      id-token: write
      contents: read
    defaults:
      run:
        shell: bash
        working-directory: ./terraform/

    steps:
    - name: Checkout
      uses: actions/checkout@v2

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-region: ${{ env.AWS_DEFAULT_REGION }}
        role-to-assume: ${{ env.AWS_ROLE_ARN }}

    - name: Setup Terraform
      uses: hashicorp/setup-terraform@v2

    - name: Init Terraform
      run: |
        terraform init 

    - name: Test Terraform
      run: |
        terraform plan 

  TF_VAR_PW_SAMPLE_APP: ${{ secrets.PW_SAMPLE_APP }}

将Sample App的登录密码存储在GitHub的环境变量中，以便在CI/CD的时机中读取并应用到Okta。

使用Terraform进行管理的好处。

从一开始，注册就很麻烦。

由于进行了代码化，可以通过复制粘贴来批量生产SWA应用程序。
在存在多个共享帐户的同一SaaS情况下，注册和定期更改密码的工作成本将大大减少。
我个人对代码化的好处感到满意，不再需要每次都进行针对SWA特定选择器的研究，并且在SaaS端进行更改时不需要更新选择器。

只能通过Okta查看登录信息，这太麻烦了。

尽管这是一种土的不满，但是我觉得Okta的管理界面在到达所需信息的过程中的转换数量和加载等待时间很长，所以能够在本地轻松查看是值得感激的。

如何管理ID/PW这样明显的认证信息？

在Bitkey上，SaaS共享帐户的ID基本上是通过使用Mailis组来进行。当然，如果想要的话，可以像密码一样将其隐藏在GitHub的环境变量中。

持续的问题（截至2023年11月）

    • SWAはGoogle Authenticatorのような多要素認証（MFA）でワンタイムパスワードを要求するタイプのSaaSには対応していません。

ただし、登録メールアドレスに対してログインの都度、認証コードを送ってくるタイプのサービスについては、メーリスに届いた認証メールをSlackなど利用者が見れる場所に転送する運用は可能です。

TerraformのOkta Providerが未対応なため、ID入力後に別ページに遷移してパスワードを入力するタイプのログインには対応できません

ただし、Oktaの管理画面上から Template Two Page Plugin App を選んで手動作成することでSSOを実現することは可能です。

最后

通过使用Okta的SWA，我们现在可以安全地使用以前共享ID/PW来运营的SaaS。由于受到Okta的认证策略控制，我们还可以实现只能从公司电脑登录的状态。

此外，从用户的角度来看，ID和密码”没有必要知道”也能提高安全性。

如果将注册到Okta变得麻烦的SaaS也进行编码，就可以轻松地批量生产Okta应用程序，因此在使用Okta SWA时，请务必考虑使用Terraform。

✖
广告
将在 10 秒后关闭
bannerAds