This component is responsible for creating AWS SSO Permission Sets and creating AWS SSO Account Assignments, that is, assigning IdP (Okta) groups and/or users to AWS SSO permission sets in specific AWS Accounts.

This component assumes that AWS SSO has already been enabled via the AWS Console (there isn't terraform or AWS CLI support for this currently) and that the IdP has been configured to sync users and groups to AWS SSO.

Tip

👽 Use Atmos with Terraform

Cloud Posse uses atmos to easily orchestrate multiple environments using Terraform.
Works with Github Actions, Atlantis, or Spacelift.

Watch demo of using Atmos with Terraform

Example of running atmos to manage infrastructure from our Quick Start tutorial.

Usage

Migration from v1.x

Version 2.0.0 introduces breaking changes. See src/MIGRATION.md for detailed migration instructions.

Key changes:

• Removed aws.root provider - deploy directly to root account instead of delegating to identity
• Removed sso_account_assignments_root module
• Moved policy files (policy-TerraformUpdateAccess.tf, policy-Identity-role-TeamAccess.tf) to mixins
• Added static account map support via account_map_enabled variable

Static Account Map Support

This component supports two modes for account ID resolution:

• account_map_enabled = true (default): Uses the account-map component to look up account IDs dynamically via remote state
• account_map_enabled = false: Uses the static account_map variable, eliminating the dependency on the account-map component

For most deployments, we recommend using static account mappings (account_map_enabled: false) for simplicity.

Clickops

1. Go to root admin account
2. Select primary region
3. Go to AWS SSO
4. Enable AWS SSO

Delegation no longer recommended

Previously, Cloud Posse recommended delegating SSO to the identity account by following the next 2 steps:

1. Click Settings > Management
2. Delegate Identity as an administrator. This can take up to 30 minutes to take effect.

However, this is no longer recommended. Because the delegated SSO administrator cannot make changes in the root account and this component needs to be able to make changes in the root account, any purported security advantage achieved by delegating SSO to the identity account is lost.

Nevertheless, it is also not worth the effort to remove the delegation. If you have already delegated SSO to the identity, continue on, leaving the stack configuration in the gbl-identity stack rather than the currently recommended gbl-root stack.

Google Workspace

Important

Your identity source is currently configured as 'External identity provider'. To add new groups or edit their memberships, you must do this using your external identity provider.

Groups cannot be created with ClickOps in the AWS console and instead must be created with AWS API.

Google Workspace is now supported by AWS Identity Center, but Group creation is not automatically handled. After configuring SAML and SCIM with Google Workspace and IAM Identity Center following the AWS documentation, add any Group name to var.groups to create the Group with Terraform. Once the setup steps as described in the AWS documentation have been completed and the Groups are created with Terraform, Users should automatically populate each created Group.

components:
  terraform:
    aws-sso:
      vars:
        groups:
          - "Developers"
          - "Dev Ops"

Atmos

Stack Level: Global Deployment: Must be deployed by root-admin using atmos CLI

Add catalog to gbl-root root stack.

account_assignments

The account_assignments setting configures access to permission sets for users and groups in accounts, in the following structure:

<account-name>:
  groups:
    <group-name>:
      permission_sets:
        - <permission-set-name>
  users:
    <user-name>:
      permission_sets:
        - <permission-set-name>

• The account names (a.k.a. "stages") must already be configured via the accounts component.
• The user and group names must already exist in AWS SSO. Usually this is accomplished by configuring them in Okta and syncing Okta with AWS SSO.
• The permission sets are defined (by convention) in files names policy-<permission-set-name>.tf in the aws-sso component. The definition includes the name of the permission set. See components/terraform/aws-sso/policy-AdminstratorAccess.tf for an example.

identity_roles_accessible (via mixin)

Note: This feature has been moved to a mixin in v2.0.0. To use it, vendor the policy-Identity-role-TeamAccess.tf mixin.

The aws_teams_accessible variable (when using the mixin) provides a list of role names corresponding to roles created in the iam-primary-roles component. For each named role, a corresponding permission set will be created which allows the user to assume that role. The permission set name is generated in Terraform from the role name using a statement like this one:

format("Identity%sTeamAccess", replace(title(replace(team, "_", "-")), "-", ""))

See mixins/README.md for details on vendoring this mixin.

Defining a new permission set

1. Give the permission set a name, capitalized, in CamelCase, e.g. AuditManager. We will use NAME as a placeholder for the name in the instructions below. In Terraform, convert the name to lowercase snake case, e.g. audit_manager.
2. Create a file in the aws-sso directory with the name policy-NAME.tf.
3. In that file, create a policy as follows:

data "aws_iam_policy_document" "TerraformUpdateAccess" {
  # Define the custom policy here
}

locals {
  NAME_permission_set = {                         # e.g. audit_manager_permission_set
    name                                = "NAME",  # e.g. AuditManager
    description                         = "<description>",
    relay_state                         = "",
    session_duration                    = "PT1H", # One hour, maximum allowed for chained assumed roles
    tags                                = {},
    inline_policy                       = data.aws_iam_policy_document.NAME.json,
    policy_attachments                  = []  # ARNs of AWS managed IAM policies to attach, e.g. arn:aws:iam::aws:policy/ReadOnlyAccess
    customer_managed_policy_attachments = []  # ARNs of customer managed IAM policies to attach
  }
}

4. Create a file named additional-permission-sets-list_override.tf in the aws-sso directory (if it does not already exist). This is a terraform override file, meaning its contents will be merged with the main terraform file, and any locals defined in it will override locals defined in other files. Having your code in this separate override file makes it possible for the component to provide a placeholder local variable so that it works without customization, while allowing you to customize the component and still update it without losing your customizations.
5. In that file, redefine the local variable overridable_additional_permission_sets as follows:

locals {
  overridable_additional_permission_sets = [
    local.NAME_permission_set,
  ]
}

If you have multiple custom policies, add each one to the list.

6. With that done, the new permission set will be created when the changes are applied. You can then use it just like the others.
7. If you want the permission set to be able to use Terraform, enable access to the Terraform state read/write (default) role in tfstate-backend.

Using Mixins

Mixins provide a way to extend the component with additional permission sets without modifying the core component code. This makes it easier to keep your components up-to-date with upstream changes while maintaining custom functionality.

Available Mixins

This component provides several mixins in the mixins/ directory:

• provider-root.tf - AWS root provider alias for migration scenarios (v1.x to v2.x upgrades)
• policy-TerraformUpdateAccess.tf - Permission set for Terraform state access
• policy-Identity-role-TeamAccess.tf - Permission sets for team role assumption
• policy-PartnerCentral.tf - AWS Partner Central permission sets for AWS Partner Network (APN) integration

See the mixins/README.md for a complete list of available mixins and detailed documentation.

Vendoring Mixins

Option 1: Via component.yaml (Recommended)

Add the mixin to your component's component.yaml file:

# components/terraform/aws-sso/component.yaml
apiVersion: atmos/v1
kind: ComponentVendorConfig
spec:
  source:
    uri: github.com/cloudposse-terraform-components/aws-identity-center.git//src?ref={{ .Version }}
    version: 1.0.0
    included_paths:
      - "**/**"
    excluded_paths: []

  # Mixins are pulled and merged into your component directory
  mixins:
    - uri: github.com/cloudposse-terraform-components/aws-identity-center.git//mixins/policy-PartnerCentral.tf?ref={{ .Version }}
      version: 1.0.0
      filename: policy-PartnerCentral.tf

Option 2: Via vendor.yaml

Use a centralized vendor.yaml file:

# vendor.yaml
apiVersion: atmos/v1
kind: AtmosVendorConfig
spec:
  sources:
    - component: "terraform/aws-sso"
      source: "github.com/cloudposse-terraform-components/aws-identity-center.git//src?ref={{ .Version }}"
      version: "1.0.0"
      targets:
        - "components/terraform/aws-sso"
      mixins:
        - source: "github.com/cloudposse-terraform-components/aws-identity-center.git//mixins/policy-PartnerCentral.tf?ref={{ .Version }}"
          version: "1.0.0"
          filename: "policy-PartnerCentral.tf"

Then run:

atmos vendor pull -c aws-sso

Activating Vendored Permission Sets

After vendoring a mixin, include the permission sets in your component by updating additional-permission-sets_override.tf:

# components/terraform/aws-sso/additional-permission-sets_override.tf
locals {
  # Add custom permission sets.
  # Mixins define local variables (e.g., local.partner_central_permission_sets)
  # that you concatenate into this list.
  overridable_additional_permission_sets = concat(
    local.partner_central_permission_sets,  # From policy-PartnerCentral.tf mixin
    # Add other permission set locals here as needed
    # local.custom_permission_sets,
  )
}

Each mixin defines a local variable containing its permission sets. For example, policy-PartnerCentral.tf defines local.partner_central_permission_sets with 8 permission sets for AWS Partner Central.

Creating Custom Mixins

You can create your own mixin files following this pattern:

# components/terraform/aws-sso/policy-CustomRole.tf
locals {
  custom_permission_sets = [
    {
      name                                = "MyCustomRole"
      description                         = "Description of the role"
      relay_state                         = ""
      session_duration                    = ""
      tags                                = {}
      inline_policy                       = ""
      policy_attachments                  = ["arn:${local.aws_partition}:iam::aws:policy/CustomPolicy"]
      customer_managed_policy_attachments = []
    },
  ]
}

Then reference it in additional-permission-sets_override.tf:

locals {
  overridable_additional_permission_sets = concat(
    local.custom_permission_sets,
    local.partner_central_permission_sets,
  )
}

For more details, see mixins/README.md.

Basic Example

The basic example shows how to configure the component with static account mappings (recommended for most deployments):

components:
  terraform:
    aws-sso:
      vars:
        enabled: true
        account_map_enabled: false
        account_map:
          full_account_map:
            core-root: "111111111111"
            core-audit: "222222222222"
            plat-dev: "333333333333"
            plat-staging: "444444444444"
            plat-prod: "555555555555"
          root_account_account_name: "core-root"

        account_assignments:
          core-root:
            groups:
              "Administrators":
                permission_sets:
                  - AdministratorAccess
                  - TerraformApplyAccess
          plat-dev:
            groups:
              "Developers":
                permission_sets:
                  - AdministratorAccess
                  - ReadOnlyAccess
          plat-prod:
            groups:
              "Developers":
                permission_sets:
                  - ReadOnlyAccess

Advanced Example with YAML Anchors

The example snippet below shows how to use this module with YAML Anchors for reusable configurations:

prod-cloud-engineers: &prod-cloud-engineers
  Production Cloud Infrastructure Engineers:
    permission_sets:
      - AdministratorAccess
      - ReadOnlyAccess

components:
  terraform:
    aws-sso:
      vars:
        enabled: true
        account_map_enabled: false
        account_map:
          full_account_map:
            core-root: "111111111111"
            core-audit: "222222222222"
            plat-dev: "333333333333"
            plat-prod: "444444444444"
          root_account_account_name: "core-root"

        account_assignments:
          core-audit:
            groups:
              <<: *prod-cloud-engineers
              Production Cloud Engineers:
                permission_sets:
                  - ReadOnlyAccess
          plat-prod:
            groups:
              Administrators:
                permission_sets:
                  - AdministratorAccess
                  - ReadOnlyAccess
              Developers:
                permission_sets:
                  - ReadOnlyAccess
          plat-dev:
            groups:
              Administrators:
                permission_sets:
                  - AdministratorAccess
                  - ReadOnlyAccess
              Developers:
                permission_sets:
                  - AdministratorAccess
                  - ReadOnlyAccess

Important

In Cloud Posse's examples, we avoid pinning modules to specific versions to prevent discrepancies between the documentation and the latest released versions. However, for your own projects, we strongly advise pinning each module to the exact version you're using. This practice ensures the stability of your infrastructure. Additionally, we recommend implementing a systematic approach for updating versions to avoid unexpected changes.

Requirements

Name	Version
terraform	>= 1.0.0
aws	>= 4.0, < 6.0.0

Providers

Name	Version
aws	>= 4.0, < 6.0.0

Modules

Name	Source	Version
account_map	cloudposse/stack-config/yaml//modules/remote-state	1.8.0
iam_roles	cloudposse/label/null	0.25.0
permission_sets	cloudposse/sso/aws//modules/permission-sets	1.2.0
sso_account_assignments	cloudposse/sso/aws//modules/account-assignments	1.2.0
this	cloudposse/label/null	0.25.0

Resources

Name	Type
aws_identitystore_group.manual	resource
aws_iam_policy_document.dns_administrator_access	data source
aws_iam_policy_document.eks_read_only	data source
aws_iam_policy_document.terraform_apply_access	data source
aws_iam_policy_document.terraform_apply_access_additional	data source
aws_iam_policy_document.terraform_plan_access	data source
aws_iam_policy_document.terraform_plan_access_additional	data source
aws_iam_policy_document.terraform_state_access	data source
aws_iam_policy_document.terraform_state_access_additional	data source
aws_identitystore_group.idp	data source
aws_partition.current	data source
aws_ssoadmin_instances.this	data source

Inputs

Name	Description	Type	Default	Required
account_assignments	Enables access to permission sets for users and groups in accounts, in the following structure: yaml : groups: : permission_sets: - users: : permission_sets: -	map(map(map(object({ permission_sets = list(string) } ))))	{}	no
account_map	Map of account names (tenant-stage format) to account IDs. Used to verify we're targeting the correct AWS account. Optional attributes support component-specific functionality (e.g., audit_account_account_name for cloudtrail, root_account_account_name for aws-sso).	object({ full_account_map = map(string) audit_account_account_name = optional(string, "") root_account_account_name = optional(string, "") identity_account_account_name = optional(string, "") aws_partition = optional(string, "aws") iam_role_arn_templates = optional(map(string), {}) })	{ "audit_account_account_name": "", "aws_partition": "aws", "full_account_map": {}, "iam_role_arn_templates": {}, "identity_account_account_name": "", "root_account_account_name": "" }	no
account_map_component_name	The name of the account-map component	string	"account-map"	no
account_map_enabled	When true, uses the account-map component to look up account IDs dynamically. When false, uses the static account_map variable instead. Set to false when using Atmos Auth profiles and static account mappings.	bool	true	no
additional_tag_map	Additional key-value pairs to add to each map in tags_as_list_of_maps. Not added to tags or id. This is for some rare cases where resources want additional configuration of tags and therefore take a list of maps with tag key, value, and additional configuration.	map(string)	{}	no
attributes	ID element. Additional attributes (e.g. workers or cluster) to add to id, in the order they appear in the list. New attributes are appended to the end of the list. The elements of the list are joined by the delimiter and treated as a single ID element.	list(string)	[]	no
context	Single object for setting entire context at once. See description of individual variables for details. Leave string and numeric variables as null to use default value. Individual variable settings (non-null) override settings in context object, except for attributes, tags, and additional_tag_map, which are merged.	any	{ "additional_tag_map": {}, "attributes": [], "delimiter": null, "descriptor_formats": {}, "enabled": true, "environment": null, "id_length_limit": null, "label_key_case": null, "label_order": [], "label_value_case": null, "labels_as_tags": [ "unset" ], "name": null, "namespace": null, "regex_replace_chars": null, "stage": null, "tags": {}, "tenant": null }	no
delimiter	Delimiter to be used between ID elements. Defaults to - (hyphen). Set to "" to use no delimiter at all.	string	null	no
descriptor_formats	Describe additional descriptors to be output in the descriptors output map. Map of maps. Keys are names of descriptors. Values are maps of the form {<br/> format = string<br/> labels = list(string)<br/>} (Type is any so the map values can later be enhanced to provide additional options.) format is a Terraform format string to be passed to the format() function. labels is a list of labels, in order, to pass to format() function. Label values will be normalized before being passed to format() so they will be identical to how they appear in id. Default is {} (descriptors output will be empty).	any	{}	no
enabled	Set to false to prevent the module from creating any resources	bool	null	no
environment	ID element. Usually used for region e.g. 'uw2', 'us-west-2', OR role 'prod', 'staging', 'dev', 'UAT'	string	null	no
groups	List of AWS Identity Center Groups to be created with the AWS API. When provisioning the Google Workspace Integration with AWS, Groups need to be created with API in order for automatic provisioning to work as intended.	list(string)	[]	no
id_length_limit	Limit id to this many characters (minimum 6). Set to 0 for unlimited length. Set to null for keep the existing setting, which defaults to 0. Does not affect id_full.	number	null	no
idp_groups	List of IdP group names to look up and include in the group_ids output. These groups are managed by your Identity Provider (e.g., Google Workspace, Okta) and synced to AWS Identity Center. This allows referencing their IDs in other components.	list(string)	[]	no
label_key_case	Controls the letter case of the tags keys (label names) for tags generated by this module. Does not affect keys of tags passed in via the tags input. Possible values: lower, title, upper. Default value: title.	string	null	no
label_order	The order in which the labels (ID elements) appear in the id. Defaults to ["namespace", "environment", "stage", "name", "attributes"]. You can omit any of the 6 labels ("tenant" is the 6th), but at least one must be present.	list(string)	null	no
label_value_case	Controls the letter case of ID elements (labels) as included in id, set as tag values, and output by this module individually. Does not affect values of tags passed in via the tags input. Possible values: lower, title, upper and none (no transformation). Set this to title and set delimiter to "" to yield Pascal Case IDs. Default value: lower.	string	null	no
labels_as_tags	Set of labels (ID elements) to include as tags in the tags output. Default is to include all labels. Tags with empty values will not be included in the tags output. Set to [] to suppress all generated tags. Notes: The value of the name tag, if included, will be the id, not the name. Unlike other null-label inputs, the initial setting of labels_as_tags cannot be changed in later chained modules. Attempts to change it will be silently ignored.	set(string)	[ "default" ]	no
name	ID element. Usually the component or solution name, e.g. 'app' or 'jenkins'. This is the only ID element not also included as a tag. The "name" tag is set to the full id string. There is no tag with the value of the name input.	string	null	no
namespace	ID element. Usually an abbreviation of your organization name, e.g. 'eg' or 'cp', to help ensure generated IDs are globally unique	string	null	no
regex_replace_chars	Terraform regular expression (regex) string. Characters matching the regex will be removed from the ID elements. If not set, "/[^a-zA-Z0-9-]/" is used to remove all characters other than hyphens, letters and digits.	string	null	no
region	AWS Region	string	n/a	yes
session_duration	The default duration of the session in seconds for all permission sets. If not set, fallback to the default value in the module, which is 1 hour.	string	""	no
stage	ID element. Usually used to indicate role, e.g. 'prod', 'staging', 'source', 'build', 'test', 'deploy', 'release'	string	null	no
tags	Additional tags (e.g. {'BusinessUnit': 'XYZ'}). Neither the tag keys nor the tag values will be modified by this module.	map(string)	{}	no
tenant	ID element _(Rarely used, not included by default)_. A customer identifier, indicating who this instance of a resource is for	string	null	no
tf_access_additional_backends	Map of additional Terraform state backends to grant SSO permission sets access to. Each entry creates three permission sets: TerraformPlanAccess-, TerraformApplyAccess-, and TerraformStateAccess-. The map key should be a descriptive name for the backend (e.g., "core", "plat", "prod"). This key will be title-cased and appended to the permission set names with a hyphen. Example: tf_access_additional_backends = { core = { bucket_arn = "arn:aws:s3:::example-core-tfstate" dynamodb_table_arn = "arn:aws:dynamodb:us-east-1:123456789012:table/example-core-tfstate-lock" role_arn = "arn:aws:iam::123456789012:role/example-core-gbl-root-tfstate" } plat = { bucket_arn = "arn:aws:s3:::example-plat-tfstate" role_arn = "arn:aws:iam::123456789012:role/example-plat-gbl-root-tfstate" } }	map(object({ bucket_arn = string dynamodb_table_arn = optional(string, "") role_arn = string }))	{}	no
tf_access_bucket_arn	The ARN of the S3 bucket for the Terraform state backend.	string	""	no
tf_access_dynamodb_table_arn	The ARN of the DynamoDB table for the Terraform state backend.	string	""	no
tf_access_role_arn	The ARN of the IAM role for accessing the Terraform state backend.	string	""	no

Outputs

Name	Description
group_ids	Group IDs for Identity Center (includes both manually created and IdP-synced groups)
permission_sets	Permission sets
sso_account_assignments	SSO account assignments

Related Projects

Check out these related projects.

• Cloud Posse Terraform Modules - Our collection of reusable Terraform modules used by our reference architectures.
• Atmos - Atmos is like docker-compose but for your infrastructure

References

For additional context, refer to some of these links.

• cloudposse/terraform-aws-sso -

Tip

Use Terraform Reference Architectures for AWS

Use Cloud Posse's ready-to-go terraform architecture blueprints for AWS to get up and running quickly.

✅ We build it together with your team.
✅ Your team owns everything.
✅ 100% Open Source and backed by fanatical support.

📚 Learn More

Cloud Posse is the leading DevOps Accelerator for funded startups and enterprises.

Your team can operate like a pro today.

Ensure that your team succeeds by using Cloud Posse's proven process and turnkey blueprints. Plus, we stick around until you succeed.

Day-0: Your Foundation for Success

• Reference Architecture. You'll get everything you need from the ground up built using 100% infrastructure as code.
• Deployment Strategy. Adopt a proven deployment strategy with GitHub Actions, enabling automated, repeatable, and reliable software releases.
• Site Reliability Engineering. Gain total visibility into your applications and services with Datadog, ensuring high availability and performance.
• Security Baseline. Establish a secure environment from the start, with built-in governance, accountability, and comprehensive audit logs, safeguarding your operations.
• GitOps. Empower your team to manage infrastructure changes confidently and efficiently through Pull Requests, leveraging the full power of GitHub Actions.

Day-2: Your Operational Mastery

• Training. Equip your team with the knowledge and skills to confidently manage the infrastructure, ensuring long-term success and self-sufficiency.
• Support. Benefit from a seamless communication over Slack with our experts, ensuring you have the support you need, whenever you need it.
• Troubleshooting. Access expert assistance to quickly resolve any operational challenges, minimizing downtime and maintaining business continuity.
• Code Reviews. Enhance your team’s code quality with our expert feedback, fostering continuous improvement and collaboration.
• Bug Fixes. Rely on our team to troubleshoot and resolve any issues, ensuring your systems run smoothly.
• Migration Assistance. Accelerate your migration process with our dedicated support, minimizing disruption and speeding up time-to-value.
• Customer Workshops. Engage with our team in weekly workshops, gaining insights and strategies to continuously improve and innovate.

✨ Contributing

This project is under active development, and we encourage contributions from our community.

Many thanks to our outstanding contributors:

For 🐛 bug reports & feature requests, please use the issue tracker.

In general, PRs are welcome. We follow the typical "fork-and-pull" Git workflow.

1. Review our Code of Conduct and Contributor Guidelines.
2. Fork the repo on GitHub
3. Clone the project to your own machine
4. Commit changes to your own branch
5. Push your work back up to your fork
6. Submit a Pull Request so that we can review your changes

NOTE: Be sure to merge the latest changes from "upstream" before making a pull request!

Running Terraform Tests

We use Atmos to streamline how Terraform tests are run. It centralizes configuration and wraps common test workflows with easy-to-use commands.

All tests are located in the test/ folder.

Under the hood, tests are powered by Terratest together with our internal Test Helpers library, providing robust infrastructure validation.

Setup dependencies:

• Install Atmos (installation guide)
• Install Go 1.24+ or newer
• Install Terraform or OpenTofu

To run tests:

• Run all tests:

  atmos test run

• Clean up test artifacts:

  atmos test clean

• Explore additional test options:

  atmos test --help

The configuration for test commands is centrally managed. To review what's being imported, see the atmos.yaml file.

Learn more about our automated testing in our documentation or implementing custom commands with atmos.

🌎 Slack Community

Join our Open Source Community on Slack. It's FREE for everyone! Our "SweetOps" community is where you get to talk with others who share a similar vision for how to rollout and manage infrastructure. This is the best place to talk shop, ask questions, solicit feedback, and work together as a community to build totally sweet infrastructure.

📰 Newsletter

Sign up for our newsletter and join 3,000+ DevOps engineers, CTOs, and founders who get insider access to the latest DevOps trends, so you can always stay in the know. Dropped straight into your Inbox every week — and usually a 5-minute read.

📆 Office Hours

Join us every Wednesday via Zoom for your weekly dose of insider DevOps trends, AWS news and Terraform insights, all sourced from our SweetOps community, plus a live Q&A that you can’t find anywhere else. It's FREE for everyone!

License

Preamble to the Apache License, Version 2.0

Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

  https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.

Trademarks

All other trademarks referenced herein are the property of their respective owners.

---

Copyright © 2017-2026 Cloud Posse, LLC