Enable OIDC Auth on the Arkime Portal

[chelma]

Description

This task is to enable users to set up OIDC Auth for the Arkime Portal. Arkime currently supports OIDC as a provider [1], so this will just be surfacing that configuration through the CLI, updating it as users change it, and ensuring the networking side of things doesn't present any problems.

Some existing discussion on this topic and how to store the data can be found in this other issue's convo history [2].

[1] https://arkime.com/settings#auth-oidc [2] https://github.com/arkime/aws-aio/issues/43

Acceptance Criteria

• User able to set up OIDC on an existing Arkime Cluster
• User able to update OIDC settings for an existing Arkime Cluster (ideally without a CloudFormation update)

[chelma]

Per discussion with @awick, here's an example Arkime Config settings for Cognito:

# Cognito OIDC Direct
userNameHeader=oidc
authDiscoverURL=https://cognito-idp.us-west-2.amazonaws.com/us-west-2_FL25HEbel
authClientId=<alphanumeric string>
authClientSecret=<alphanumeric string>
authUserIdField=email
authRedirectURIs=https://<domain>:4443/auth/login/callback
userAutoCreateTmpl={"userId": "${this.preferred_username}", "userName": "${this.name}", "enabled": true, "webEnabled": true, "headerAuthEnabled": true, "emailSearch": true, "createEnabled": false, "removeEnabled": false, "packetSearch": true }

Also per discussion, the authClientSecret is pre-negotiated with the OIDC provider and will need to be supplied by the user. It turns out that Python has a built-in method for accepting passwords [1] we can use. After sending it to AWS Secrets Manager, we can del the variable. It'll stick around in memory until the garbage collector deems fit to reap it, but I think that's the best we can do in Python.

[1] https://docs.python.org/3.10/library/getpass.html

[chelma]

Taking a look at the AWS AppConfig docs, it does seem suitable for our usecase here and has good integration w/ ECS [1]. AppConfig gets deployed in a sidecar container and exposes the config over localhost at a set port that your application container can curl.

[1] https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-integration-containers-agent.html

[chelma]

OK, I think the work streams here is as follows:

(1) Move all existing Container configuration from Environment Variables to AWS AppConfig (2) Add new CLI command (configure-oidc, maybe?) that adds the OIDC specific configuration and bounces the container fleet without a CloudFormation Update

Need to do (1) first to reduce re-work. I think we can make configure-oidc idempotent so we don't need a second command for updates. We may want to add a --remove option to convert back to basic auth.

Will create sub-tasks since these are individually meaty items.

[awick]

1) Just to clarify, only the viewer container fleet needs to be bounced, capture doesn't care about viewer auth methods 2) Maybe want to plan ahead for other auth methods in the command name maybe something like configure-auth-oidc, configure-auth-builtin instead of a --remove, it would replace whatever is already there.

[chelma]

After discussion in this RFC (https://github.com/arkime/aws-aio/issues/81), this task is effectively to just do the following subtasks:

• https://github.com/arkime/aws-aio/issues/80
• https://github.com/arkime/aws-aio/issues/77

[chelma]

Completed in https://github.com/arkime/aws-aio/pull/117