Skip to content


While Figgy does require AWS at this time, organizations running Kubernetes in AWS can still take full advantage of Figgy's feature suite. Currently there is no cross-platform support for other cloud providers, so if your organization intends to run multi-cloud K8s clusters, Figgy is not a good fit at this time. However, if you are content with AWS and do not have immediate plans to run K8s across multiple clouds, Figgy can offer distinct advantages over native K8s components for configuration and secret management.

Why not native K8s ConfigMaps and Secrets?#

  • K8s Secrets & Config Maps are cluster specific. You cannot share configurations across clusters.
  • K8s ConfigMaps and Secrets lack versioning and change management.
  • Users who consume secrets can see the value.
  • No CICD build validation.
  • K8s lacks the secret-sharing features that Figgy offers.
  • Any user with root access on any K8s node can read any secret.
  • Subjectively, K8s ConfigMaps and Secrets are more complex to manage than using a service like AWS ParameterStore.

Still Determined to K8s Secrets?#

ParameterStore can be used to elegantly hydrate K8s secrets.

Since Figgy is built on AWS ParameterStore, each service deployed in K8s will need access to its Figgy Twig through standard AWS IAM access control. If your K8s cluster is deployed in EKS, we strongly recommend you look into the AWS IAM + K8s Service Account integration. You may also leverage tools like kube2iam or kiam to provide appropriate access to your K8s services.

For an AWS IAM policy reference, see the IAM Cookbook.

Got ideas of how to improve K8s and Figgy integrations? Let us know on Github!