5.7 KiB
IROH-Auth PTO knowledge sharing
- tags
- cisco
- source
IROH-Auth Maintenance
Daily tasks ; scripts
- create a global OAuth2 master client creds
-
configure it into a
~/.cisco.sh.gpgcontainingIROH_CLIENT_ID="client-xxxxx" IROH_CLIENT_SECRET="client-xxxxx" IROH_PROVISIONING_CLIENT_ID="client-xxxxx" IROH_PROVISIONING_CLIENT_SECRET="client-xxxxx"and then
gpg -dq ~/.cisco.sh.gpg|source - Connect to all admin VPN
-
Use the scripts; here are the most useful and recently used ones:
iroh-scripts/ ├── add-admin-to-org ├── add-ai-assistant ├── add-flag.sh ├── remove-flag.sh ├── get-client ├── patch-client ├── add-scopes-to-client ;; <- takes care of scopes in the org ├── add-scopes-to-org ├── ai-direct-onboard ;; <- just onboard but do not show; need feature-flag └── client-pass xdr-provisioning/ ├── add-flag.sh ├── add-xdr-flag.sh ├── full-reprovision.sh ├── re-provision.sh ├── sc-provision.sh ;; <- never used for real one of my task to check, not sure I could ├── sx-only-provision.sh ├── tsv-to-commands.sh └── xdr-provision.sh
Recent daily tasks
- add XDR flag to some QA org
- remove XDR flag to some PROD org (from Danny)
- patch clients from different sources, mixed with webhooks?
Provisioning & Onboardings
Too many Provisioning APIs
- SXSO migration ⇒
/iroh/provisioning - PIAM pre-universal ⇒
/iroh/provisioning/platform - PIAM universal (real) ⇒
/iroh/external-provisioningonly PIAM tokens - PIAM universal copy for QA ⇒
/iroh/provisioning/universal-provisioning
After SX EOL: TWO Provisioners;
- PIAM via universal provisioning API and
- SE via PIAM pre-universal API.
Onboarding
- XDR: PIAM Onboarding: CSC, SXO, DI, SCA
- SC-UI (sometime called SCM): SE Onboarding: SE, CSC, Orbital, DI
The onboarding conf is mostly what you would put in the clj-http/post.
Recent bugs/weakness:
- body template… ⇒ risk to break content-type and/or parsing as json
- body passed in the request ⇒ no control on this thing….
- Universal Provisioning ⇒ separate but similar onboarding service… THAT'S BAD… PR in progress, probably not able to finish
Current risks/potential bugs
PIAM Universal Provisioning
Universal Provisioning callback. Flow is:
- PIAM -> IROH (provides IROH a CALLBACK_URL)
- IROH -> External Onboarding Service
- External Onboarding Service -> IROH: save body in callback-response
- After all onboarding have answered, send response to CALLBACK_URL provided by PIAM
Wanderson told me, in EU, some does not have any callback url, but PIAM did not have these as error on their side.
If an error occurs, we should still respond to PIAM otherwise it is an error on their side, even if things went well on ours. There is a cron job, generally just changing the state in the store, will be enough for the cron job to take care of the rest and return the answer to PIAM. There is also an endpoint to trigger the cron manually of course.
SE Provisioning
We added the onboarding orbital but SE is sending a specific body via the
onboarding API to Orbital. So you cannot use the onboarding for orbital directly.
SE is mostly alone in dealing with the provisioning. Their client should have all mandatory scopes, but there is a risk they want more.
SX EOL quickly
The flags
In order to not show the feature-flag mixed with the scopes, there is a new
field flags inside the Org.
A single flag has some effect: sc.
If you have this flag, you cannot use SX and are redirected to SC.
After SX EOL, this flag will not have any effect.
Plan to add a flag with effect with sx so QA could still use SX in TEST for 1
year after SX EOL.
Managing the flags
https://stunning-barnacle-e4478e20.pages.github.io/admin-ui/
Use FF-UI or the scripts
Note the scopes required to add/remove the flag.
Changed, with should be given to TAC, to should not be given to TAC.
The APIs are hidden under the provisioning APIs both for: flags and feature-flag-scopes.
If possible let's deprecate feature-flag-scopes even if probably the xdr
feature-flag will be there forever.
Redirections
There are new dynamically built fields apps and main-app.
appsthe application the user can usemain-appthe application the user should default to when we have different choices.
There is a new apps section in the config to know which URL we can use for apps.
{:global
{:apps
{:sc
{:module-type-ids-allow-list
;; would be better with aliases in the config, now with aero we can do it
#{"03d8591b-8374-5666-8fcc-eaea9188193c"
"b6a282ad-be30-4382-b27f-7346320e3b84"
"b7f21c6b-701a-4b45-8a3d-449001844efe"
"b95d5cd0-5bcb-45f6-921c-e2777468f6b0"}
:url "https://secure-client.us.security.cisco.com"}
:sx
{:module-type-ids-allow-list :all,
:url "https://securex.us.security.cisco.com"}
:xdr
{:module-type-ids-allow-list :all,
:url "https://xdr.us.security.cisco.com"}}
}This is used by both the UI and the backend to decide where to redirect users. The rules are a bit complex, but we try our best to prevent a redirect hop via a UI if we have enough details.