Identity Platform CI/CD Manifest Pipeline

Pipeline Overview

accessctl GitLab CI/CD Pipeline Jobs

Provisioning Stage

GitLab Self-Managed Instance API

GitLab.com SaaS API

Google Workspace Directory API

Okta API

Stage 3.5
GitLab Self-Managed Groups Job
provision:gitlab-self-groups

Stage 3.1
Okta Users Job
provision:okta-users

Stage 3.2
Okta Groups Job
provision:okta-groups

Stage 3.3
Google Groups Job
provision:google-groups

Stage 3.4
GitLab SaaS Groups Job
provision:gitlab-saas-groups

Auditlog Stage

Stage 2.1
Users Job
CLI auditlog:users

Stage 2.2
Attributes Job
CLI auditlog:attributes

Stage 2.3
Roles Job
CLI auditlog:roles

Stage 2.4
Org Units Job
CLI auditlog:ou

Manifest Stage

Stage 1.1
Users Job
CLI manifest:users

Stage 1.2
Roles Job
CLI manifest:roles

Stage 1.3
Org Units Job
CLI manifest:ou

accessctl GitLab Repositories

accessctl-auditlog Repo

auditlog/users/
onboarding.yml/json/csv

auditlog/users/
offboarding.yml/json/csv

auditlog/users/
attributes.yml/json/csv

auditlog/attribute/
{attribute}.yml/json/csv

auditlog/role/
{role}.yml/json/csv

auditlog/ou/
{ou}.yml/json/csv

accessctl-manifests Repo

manifests/users/
users.yml/json/csv

manifests/attributes/
{attribute}.yml/json/csv

manifests/roles/
{role}.yml/json/csv

manifests/ou/
{ou}.yml/json/csv

accessctl-policies Repo

policies/role/{kingdom}.yml

policies/ou/{kingdom}.yml

CI/CD Job Workflows

Identity GitLab Repositories

Identity GitLab Repositories

Identity Platform CI/CD Manifest Stage Scripts

Identity SaaS Vendor Services

Workday

accessctl-inventory Repo

accessctl-policies Repo

Okta GitLab Tenant

Manager Relationship

SCIM Provisioning
Every Hour

Worker

Region

Department

Division

Job Title

Workday to Okta
Profile Mapping

Okta Users

Okta API
Unsupported markdown: link

Stage 1.1
Users Job
CLI manifest:users

Stage 1.2
Roles Job
CLI manifest:roles

Stage 1.3
Org Units Job
CLI manifest:ou

Get All Users
from Okta API

Transform users with
snake_case attributes

Create manifest of users

Create manifest of unique
attributes and count of users

Parse Users
Parse Attributes
Parse Policies
Parse Policy Rules

Validate attribute keys exist
for each policy rule

Get users
for each policy handle

Get users
for each Attribute Key

Create manifest of users
with unique email addresses
for each role

Parse Users
Parse Roles
Parse Attributes
Parse Policies
Parse Policy Rules

Validate attribute keys
and role keys exist
for each policy rule

Get users
for each policy handle

Get users
for each Role Key

Get users
for each Attribute Key

Create manifest
with unique email addresses
for each group

policies/role/{kingdom}.yml

policies/ou/{kingdom}.yml

manifests/users/
users.yml/json/csv

manifests/attributes/
{attribute}.yml/json/csv

manifests/roles/
{role}.yml/json/csv

manifests/ou/
{ou}.yml/json/csv

REPO_INV_MANIFESTS_GROUPS

Policy and Manifest Breaking Changes

Attribute Key No Longer Exists

When a policy is parsed prior to creating a manifest, the manifests/attributes/{attribute}.yml file is parsed to verify that the attribute key exists. This file includes the latest list of unique values from users in the Okta API.

This will detect if a department, division, title, etc no longer exists (ex. has been renamed upstream).

If a policy uses an attribute key value that no longer exists, no updated manifest will be created so the current (previous) state will be retained. This freezes the current manifest until the policy is updated by Identity Operations and the policy CODEOWNERS.

See the updating keys in policies documentation to learn how this process has been partially automated.

Manager No Longer Exists

Similar to an attribute key that no longer exists, every manager value is verified against the latest manifest of users. This will ensure that the user has not been offboarded and email handle hasn’t changed (ex. maiden name change).

If the manager user no longer exists based on the manager handle defined in the policy, no updated manifest will be created so the current (previous) state will be retained. This freezes the current manifest until the policy is updated by Identity Operations and the policy CODEOWNERS.

See the updating keys in policies documentation to learn how this process has been partially automated.

Updating Keys in Policies

If a key in a policy cannot be found, a branch and merge request is automatically created by accessctl and the CODEOWNERS and Identity Operations team members are assigned to make edits.

A comment is posted automatically to the merge request with the list of the previous manifest users and their latest updated values for the key of the value that does not exist anymore. This automates the research work to determine what the new values appear to be upstream that can be verified or adjusted by CODEOWNERS.

The policy manifest remains frozen until the changes are made. After the branch is merged, an updated manifest will be created on the next pipeline run which automatically heals the problem.

Last modified November 14, 2024: Fix broken external links (ac0e3d5e)