Skip to main content

Assess Okta Security with cnspec

Rely on cnspec to enforce policy for your Okta domain, including users, groups, policies, rules, applications and more.

Configure access to Okta

Create an Okta API token. Carefully record the API token and your Okta domain.

note

Okta API tokens have a fixed expiration period of 30 days.

Test access using the cnspec shell in a terminal. If your domain includes '-admin', you must remove it when specifying the organization to cnspec. For example, if your Okta URL is 'dev-22556123-admin.okta.com', specify your organization as 'dev-22556123.okta.com'.

$ cnspec shell okta --organization dev-22556123.okta.com --token <api-token>
___ _ __ ___ _ __ ___ ___
/ __| '_ \/ __| '_ \ / _ \/ __|
| (__| | | \__ \ |_) | __/ (__
\___|_| |_|___/ .__/ \___|\___|
mondoo™ |_|
...
cnspec> okta.organization{ * }
okta.organization: {
address2: ""
subdomain: "dev-22556123"
created: 2023-01-19 19:35:32 +0000 UTC
lastUpdated: 2023-01-19 19:35:38 +0000 UTC
country: ""
status: "ACTIVE"
website: "https://developer.okta.com"
endUserSupportHelpURL: ""
state: ""
address1: ""
city: ""
phoneNumber: ""
expiresAt: null
supportPhoneNumber: ""
postalCode: ""
companyName: "okta-dev-22556123"
id: "<REDACTED>"
}

You can also use the OKTA_CLIENT_TOKEN environment variable, which makes the --token parameter optional. Note that if both are present, the OKTA_CLIENT_TOKEN environment variable takes precedence.

$ export OKTA_CLIENT_TOKEN='00zr0k74_-s5mp13t0k3n'
$ cnspec shell okta --organization dev-22556123.okta.com
info

Want a place to experiment? Okta makes it easy to obtain Developer Accounts. Sign up at developer.okta.com/signup.

Example queries and checks

Query users

Example query:

okta.users{
profile
status
lastUpdated
credentials['provider']['name']
}

Example shell output:

okta.users: [
0: {
status: "PROVISIONED"
profile: &map[email:suki@lunalectric.com firstName:Suki lastName:Mbeze login:suki@lunalectric.com mobilePhone:<nil> secondEmail:<nil>]
lastUpdated: 2023-01-20 23:49:58 +0000 UTC
credentials[provider][name]: "OKTA"
}
1: {
status: "PROVISIONED"
profile: &map[email:alice@lunalectric.com firstName:Alice lastName:Freedman login:alice@lunalectric.com mobilePhone:<nil> secondEmail:<nil>]
lastUpdated: 2023-01-20 23:49:41 +0000 UTC
credentials[provider][name]: "OKTA"
}
2: {
status: "RECOVERY"
profile: &map[email:ben@lunalectric.com firstName:Ben lastName:Pesoa login:ben@lunalectric.com mobilePhone:<nil> secondEmail:<nil>]
lastUpdated: 2023-01-19 20:14:53 +0000 UTC
credentials[provider][name]: "OKTA"
}
]

Audit applications

This query will output the name, status, label, and sign-on mode for each configuration application:

okta.applications {
status
name
label
signOnMode
}

Example shell output:

okta.applications: [
0: {
status: "ACTIVE"
name: "saasure"
label: "Okta Admin Console"
signOnMode: "OPENID_CONNECT"
}
1: {
status: "ACTIVE"
name: "okta_end_user"
label: "Okta Dashboard"
signOnMode: "OPENID_CONNECT"
}
2: {
status: "ACTIVE"
name: "okta_browser_plugin"
label: "Okta Browser Plugin"
signOnMode: "OPENID_CONNECT"
}
3: {
status: "ACTIVE"
name: "dev-22556257_pagerduty_1"
label: "PagerDuty"
signOnMode: "AUTO_LOGIN"
}
]

Audit all access policies to ensure they're active

This query finds all access policies. For each access policy found, cnquery returns the name, priority, and status. It asserts that each rule's status should be active:

okta.policies{
accessPolicy {
name
priority
status
rules {
status == "ACTIVE"
}
}
}

Example output:

okta.policies: {
accessPolicy: [
0: {
status: "ACTIVE"
rules: [
0: {
status == "ACTIVE": true
}
]
name: "Okta Admin Console"
priority: 1
}
1: {
status: "ACTIVE"
rules: [
0: {
status == "ACTIVE": true
}
]
name: "Default Policy"
priority: 1
}
....

Learn more