You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Had a great discussion with a potential enterprise user; capturing their thoughts/requests/concerns here for posterity:
User requested a way to provision the IAM resources separately from the rest of the AWS Resources. This is due to their Security Team having permission to perform iam::* operations, but their DevOps teams not having those permissions. One solution here is a separate command (setup-iam, etc) that spins up an IAM Resource stack that the other stacks consume during create-cluster. Will have to investigate which existing resources need IAM changes.
User requested the ability to set the CIDR for the capture VPC
User requested making the filtering rules configurable (e.g. "only traffic from this CIDR")
User requested a way to provide their own cert/DNS name for the Viewer's LB. They were happy with providing an ACM ARN for the cert and dealing with the creation and storage, and acquiring the domain.
User required that all S3 objects be KMS-encrypted (didn't need a specific key, just any KMS key)
User would like SAML as an auth option eventually
User would like the tool to support the usersElasticsearch and usersPrefix settings so Arkime Viewer can use shared authZ, this may remove the saml requirement if onprem multiviewer talking to aws is supported
User would love better tools for pre-deployment cost estimation. We currently provide an indication of the main resources we're creating; we should combine that with public pricing info to give a ballpark monthly cost estimate.
User indicated they want to install custom software in-container; we should provide them a bash file they can modify for special behavior, stick it in-container, and source it on container start.
In discussions afterwards, it became clear that making the config.ini files more user-accessible in a no-code way would save everyone time/pain. We'll need to look at how to provide a satisfactory experience for that.
The text was updated successfully, but these errors were encountered:
Had a great discussion with a potential enterprise user; capturing their thoughts/requests/concerns here for posterity:
iam::*
operations, but their DevOps teams not having those permissions. One solution here is a separate command (setup-iam
, etc) that spins up an IAM Resource stack that the other stacks consume duringcreate-cluster
. Will have to investigate which existing resources need IAM changes.source
it on container start.In discussions afterwards, it became clear that making the
config.ini
files more user-accessible in a no-code way would save everyone time/pain. We'll need to look at how to provide a satisfactory experience for that.The text was updated successfully, but these errors were encountered: