Layered + installable constraints

[jlongtine]

I'll start this discussion with a specific use case to help ground the general idea I'm interested in solving for.

cfn-cue creates structs which form the basis for creating CloudFormation templates using CUE. As an example, here is a simplified version of an S3 bucket for demonstration purposes:

#Bucket: {
  Type: "AWS::S3::Bucket"
  Properties: {
    BucketEncryption?: {
      ServerSideEncryptionConfiguration: [...{
        BucketKeyEnabled?:              bool | fn.#Fn
        ServerSideEncryptionByDefault?: {
          KMSMasterKeyID?: string | fn.#Fn
          SSEAlgorithm:    ("AES256" | "aws:kms") | fn.#Fn
        } | fn.#If
      }] | fn.#If
    } | fn.#If
    BucketName?:        (strings.MinRunes(3) & strings.MaxRunes(63) & (=~#"^[a-z0-9][a-z0-9.-]*[a-z0-9]$"#)) | fn.#Fn
    Tags?: [...{
      Key:   string | fn.#Fn
      Value: string | fn.#Fn
    }] | fn.#If
  }
}

The above would be installable as a part of the github.com/cue-sh/cfn-cue module.

The thing I'd like to do is create a module that would act as a set of constraints on top of github.com/cue-sh/cfn-cue . This would be useful for setting further constraints on top of the base CloudFormation structs for compliance (such as HIPAA), security, etc.

An example for AWS::S3::Bucket

#Bucket: {
  Type: "AWS::S3::Bucket"
  Properties: {
    BucketEncryption: {
      ServerSideEncryptionConfiguration: [...{
        BucketKeyEnabled:              true
        ServerSideEncryptionByDefault: {
          KMSMasterKeyID: string | fn.#Fn
          SSEAlgorithm:    "aws:kms"
        }
      }]
    }
  }
}

Basically, I want to enforce that the users must turn on Bucket encryption and use a KMS key for that encryption.

I know that I could simply install this constraint into the cue.mod/usr folder, but I'm wondering if there would be a good way to make constraints like this installable using the module system.

I can imagine similar constraints for Kubernetes (which set reasonable security defaults for podSpec for instance).

@myitcv Any thoughts about this use case for modules?

[verdverm]

• What then would be the user experience? (i.e. What does the developer write for their buckets)
• Could you achieve this outcome using conjunctions?

For a conjunction solution, define the HIPAA version to come from the CFN bucket

package hipaa

import "foo.bar/cfn"

#Bucket: cfn.#Bucket & {
  // how you defined HIPAA bucket refinements above
}

Then use the HIPAA module in place of the CFN module

import (
  "foo.bar/hipaa"
)

myBucket: hipaa.#Bucket & { ... }

You could also arrange things such that the only thing users need to change is the import statement, by making the refined / constrained modules have the same package name as the original.

Maybe you want this to be more like the admission controllers in Kubernetes which can automatically change incoming specs?

[myitcv]

@jlongtine sorry for the slow reply. I'm not entirely clear where the modules aspect of this comes in? As @verdverm suggested, this feels more like a decision on how to structure packages/definitions such that the end-user experience "feels" right, whether it be importing the HIPAA version, or performing the composition themselves. In that regard, the query proposal (#165) feels more related here, because that would allow a general specification of further (HIPAA) constraints, whether as the end user or enforced via some policy.

[cueckoo]

This discussion has been migrated to cue-lang/cue#920.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.