We only want to accept certain strings for the os.

Is your feature request related to a problem? Please describe.
When launching an instance and bootstrapping to Chef in userdata there is currently no indication that it succeeded. Previously Terraform just always accepted the instance as a success. This would mean manual verification and false positives for successful stack convergence.

Describe the solution you'd like
Use CreationPolicy and wait for a userdata cfn-signal to succeed. See here.

Describe alternatives you've considered
None. If we want a userdata tie in this is the way. This was not possible in Terraform (at least when we actively developed Terraform).

Additional context
Knowing for sure we succeeded is key for instance service launches.

Proposed implementation
TBD. This is new territory.

Any currently forseeable downsides to this approach
This solves downsides for other items. If it works this has major upsides.

Is your feature request related to a problem? Please describe.
Currently instance creation is faced with a challenge:

The following criteria is needed to successfully launch an instance that requires any secret from Vault (most things do, even if its just a Sentry DSN).

• An IAM principal of some kind needs created
• This IAM principal needs to be added to a Vault role as a bound principal
• That Vault role needs to grant the rights to the secret

The problem is that AWS Auth role creation for Vault isn't supported directly in CloudFormation and therefore not in the AWS CDK. Doing so would require significant and complicated custom Cloudformation Registry Resources. This means we somehow need to create a role that knows about a IAM principal that is not created yet.

Describe the solution you'd like
Utilize a mix of well defined IAM policies and the role_tag feature of AWS Auth to create roles ahead of time that do not need awareness about the exact principal that will use the role and instead get access granted by the role_tag. This will require working with good IAM policies and Service Control Policy guard rails to avoid any accidental elevation.

Describe alternatives you've considered

• We could make sure the IAM principal has a predictable name, but then we must implement a naming policy that always produces unique names that are somehow also predictable. Doesn't seem like a winning scenario (this was required for terraform and a frequent PITA)
• We can create the role after launch, but then we lose the ability to configure directly on launch and must handle access failures as if they aren't an error. That's not ideal either. We want to know if a launch resource was configured correctly and lacking access is not correctly.
• We could use roles that use a wildcard principal. However this means lots of roles could match and generally seems less explicit then we'd prefer.

Additional context

Proposed implementation
TBD this requires research

Any currently forseeable downsides to this approach
Highly complex and basically requires good AWS Organization work.

• Should be enabled and disabled with a property
• Should add an IAM policy with access to cloudwatch logging groups

Is your feature request related to a problem? Please describe.
Terraform used to support (no longer does) a Chef provider that allowed setting up a Chef role. This allowed us to treat a Chef role as a stack resource and dynamically determine run list items and attributes. This functionality is key for delivering consistent configuration. Especially where instance services may need to be aware of AWS context that could be provided as attributes.

Describe the solution you'd like
TBD but thoughts so far:

Getting context about the stack that would typically be provided by role attributes:

• Provide required context as tags on the instance which we should then be able to access in code with Ohai or some other manner
  or
• Use stack outputs to provide context which we should then be able to access in code with Ohai or some other manner

Long term run list management

• Custom resource work
  or
• Just manage them manually

Describe alternatives you've considered
NA the choices are above

Additional context
Example use case. If a stack creates a resource like an S3 bucket the instance then needs to use for backups it needs to know the bucket name. How does it find out?

Proposed implementation
TBD

Any currently forseeable downsides to this approach
Complex to solve.

Is your feature request related to a problem? Please describe.
We need to securely deliver a Chef validator key to each instance one time only. Once the key is retrieved the validator key needs to not be able to be retrieved again.

Describe the solution you'd like
In Terraform this used a separate role specifically for validator retrieval. Given the instance may also have Vault secrets beyond the validator I think this is the solution we should carry forward.

Describe alternatives you've considered
There isn't a particularly good alternative for delivering a validator. We dont want the validator to be available to the instance beyond its useful window (bootstrapping to Chef). Other implementations like utilizing Systems Manager, placing the key in userdata, placing the key in AWS Secrets Manager, or placing the key in parameter store all have the downside of being available indefinitely.

There is an alternative to this approach entirely. Using AWS SSM and the AWS-ApplyChefRecipes document. However there isn't a nice way to do this during userdata phase of instance setup and it adds another challenge of locking down access to SSM run command actions.

Additional context
While this issue is for porting the feature from Terraform to CDK code this replaces the more classic need to bootstrap an instance to Chef after launch and addresses the removal of Chef provisioners from tools like Terraform in later versions.

Proposed implementation
The code from Terraform is below. Here is some key details:

• Only allow one use, cause that is all that's needed
• Applies the policy for access to the validator key
• Specified ec2 auth type which is required for the "only once" authentication
• disallow_reauthentication allows one single token grant per instance ID

We'd likely want to change some of the bindings and see if we can bind to the account id, vpc, subnets, etc without binding to a specific instance ARN.

resource "vault_aws_auth_backend_role" "instance_bootstrap" {
  count = var.uses_chef ? 1 : 0
  role = "${local.environment}-${var.name}-${data.aws_region.current.name}_bootstrap"

  auth_type = "ec2"

  bound_account_ids = [data.aws_caller_identity.default.account_id]
  bound_vpc_ids = [data.aws_vpc.default.id]
  bound_subnet_ids = data.aws_subnet_ids.target.ids
  bound_iam_instance_profile_arns = [aws_iam_instance_profile.instance.arn]

  token_ttl = 60
  token_max_ttl = 60
  token_num_uses = 1
  token_policies = ["default", "terraform-validator"]

  disallow_reauthentication = true
}

Any currently forseeable downsides to this approach
Very complex. But that's security and Vault. So no surprises there.