179 lines
5.7 KiB
Org Mode
179 lines
5.7 KiB
Org Mode
:PROPERTIES:
|
|
:ID: 64f9dd41-188c-47de-867e-fa70a2ee9e18
|
|
:END:
|
|
#+title: IROH-Auth PTO knowledge sharing
|
|
#+Author: Yann Esposito
|
|
#+Date: [2024-07-29]
|
|
|
|
- tags :: [[id:ce893df9-32a4-44e0-9eb5-b9817141ee6a][cisco]]
|
|
- source ::
|
|
|
|
* IROH-Auth Maintenance
|
|
|
|
** Daily tasks ; scripts
|
|
|
|
1. create a global OAuth2 master client creds
|
|
2. configure it into a =~/.cisco.sh.gpg= containing
|
|
|
|
#+begin_src bash
|
|
IROH_CLIENT_ID="client-xxxxx"
|
|
IROH_CLIENT_SECRET="client-xxxxx"
|
|
IROH_PROVISIONING_CLIENT_ID="client-xxxxx"
|
|
IROH_PROVISIONING_CLIENT_SECRET="client-xxxxx"
|
|
#+end_src
|
|
|
|
and then
|
|
|
|
~gpg -dq ~/.cisco.sh.gpg|source~
|
|
|
|
3. Connect to all admin VPN
|
|
4. Use the scripts; here are the most useful and recently used ones:
|
|
|
|
#+begin_src
|
|
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
|
|
#+end_src
|
|
|
|
*** 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-provisioning~ only 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:
|
|
|
|
1. PIAM -> IROH (provides IROH a /CALLBACK_URL/)
|
|
2. IROH -> External Onboarding Service
|
|
3. External Onboarding Service -> IROH: save body in callback-response
|
|
4. 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~.
|
|
|
|
- ~apps~ the application the user can use
|
|
- ~main-app~ the 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.
|
|
|
|
#+begin_src clojure
|
|
{: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"}}
|
|
}
|
|
#+end_src
|
|
|
|
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.
|
|
|
|
** Change SX EOL API
|
|
|
|
https://iroh-adm.test.iroh.site/admin/maintenance/index.html#/ReleaseBehaviorManagement/put_admin_maintenance_release_behaviors__deadline_id_
|