v0.10.1

🐛 Bug Fixes

Update iam-policy 2.0.0 -> 2.0.1 @Nuru (#53)

what

• Update iam-policy 2.0.0 -> 2.0.1

why

• Fix bug when iam_policy_statements is a tuple that cannot be converted to a list

references

• cloudposse/terraform-aws-iam-policy#31

v0.10.0 restores pre-v0.8.2 behavior, adds typed inputs

Update iam-policy to v2.0.0 @Nuru (#51)

what

• Update terraform-aws-iam-policy to version 2.0.0

why

• Previous update to version 1.x inadvertently removed the ability to accept a list of statements in iam_policy_statements. This update restores that ability, and adds additional options for input supported by terraform-aws-iam-policy

references

• terraform-aws-iam-policy v2.0.0 release notes

v0.9.3

🤖 Automatic Updates

Update Terraform cloudposse/eks-iam-role/aws to v2.1.1 (main) @renovate (#49)

This PR contains the following updates:

Package	Type	Update	Change
cloudposse/eks-iam-role/aws (source)	module	patch	2.1.0 -> 2.1.1

---

Release Notes

cloudposse/terraform-aws-eks-iam-role (cloudposse/eks-iam-role/aws)

v2.1.1

Compare Source

🚀 Enhancements

Do not validate inputs when disabled @​Nuru (#​37)

what

• Replace variable validations with precondition

why

• Variable validation cannot take other variables into account. With precondition, we can allow invalid inputs when the module is disabled.

references

• Supersedes and closes #​35

---

v0.9.2

🚀 Enhancements

feat: Add iam_policy_enabled to allow IAM roles without policies @dennislapchenko (#47)

what

• New variable iam_policy_enabled which allows creating iam eks role without a policy.
• Also changed ["{}"] to [] in module "eks_iam_role".aws_iam_policy_document when iam_policy_enabled is true. as "{}" is still an item and the module was still attempting to create a policy. (because its based on length(var. aws_iam_policy_document))

why

• When utilizing resource-based-policies access is granted on that specific resource, role that is granted access can have no policies at all, which is often a desired case.
• On this issue it was suggested that deny * policy can always be used when no policy is desired. But this does not work when using resource based policies, as the role is denied all access, including the on in resource's policy
• In my particular case I had a KMS key that allowed a role to decrypt using this key. The role needed no policies, so following the suggestion mention above I added deny all policy, which prevented by role from using the key. Removing the policy made things work, so this feature clearly has a valid use case.

references

• Fixes #37
• From AWS IAM documentation: Evaluating identity-based policies with resource-based policies

Identity-based policies and resource-based policies grant permissions to the identities or resources to which they are attached. When an IAM entity (user or role) requests access to a resource within the same account, AWS evaluates all the permissions granted by the identity-based and resource-based policies. The resulting permissions are the total permissions of the two types. If an action is allowed by an identity-based policy, a resource-based policy, or both, then AWS allows the action. An explicit deny in either of these policies overrides the allow.

v0.9.1

🤖 Automatic Updates

Update Terraform cloudposse/eks-iam-role/aws to v2.1.0 (main) @renovate (#41)

This PR contains the following updates:

Package	Type	Update	Change
cloudposse/eks-iam-role/aws (source)	module	minor	2.0.0 -> 2.1.0

---

Release Notes

cloudposse/terraform-aws-eks-iam-role

v2.1.0

Compare Source

• No changes

---

v0.9.0

🤖 Automatic Updates

Update Terraform cloudposse/iam-policy/aws to v1.0.1 (main) @renovate (#46)

This PR contains the following updates:

Package	Type	Update	Change
cloudposse/iam-policy/aws (source)	module	patch	1.0.0 -> 1.0.1

---

Release Notes

cloudposse/terraform-aws-iam-policy

v1.0.1

Compare Source

🚀 Enhancements

fix: support JSON inputs for policy document when IAM policy/statements are not set as Terraform objects @​gberenice (#​28)

what

• Consider JSON source policy documents in the recently added precondition block.

why

• It's expected to support JSON inputs while var.iam_policy and var.iam_policy_statments may remain unset. The precondition fails in this case:

│ Error: Resource precondition failed
│ 
│   on .terraform/modules/iam_policy/main.tf line 90, in data "aws_iam_policy_document" "this":
│   90:       condition     = var.iam_policy_statements != null || var.iam_policy != null
│     ├────────────────
│     │ var.iam_policy is null
│     │ var.iam_policy_statements is null
│ 
│ Exactly 1 of var.iam_policy and var.iam_policy_statments may be used, preferably var.iam_policy.

references

• N/A

---

v0.8.2 Breaking Change, reverted in v0.10.0

Breaking Change

This update to v0.8.2 inadvertently introduced a breaking change, reverted in v0.10.0.

Although the iam_policy_statements input was documented as taking a map, in fact it accepted either a map or a list. In this v0.8.2 release it was limited to taking a map, breaking everything that provided a list. This change was reverted in v0.10.0.

🤖 Automatic Updates

Update Terraform cloudposse/iam-policy/aws to v1 (main) @renovate (#45)

This PR contains the following updates:

Package	Type	Update	Change
cloudposse/iam-policy/aws (source)	module	major	0.4.0 -> 1.0.0

---

Release Notes

cloudposse/terraform-aws-iam-policy

v1.0.0: Accept policy as fully defined object

Compare Source

What's Changed

• feat: define iam_policy_statements object syntax by @​gberenice in https://github.com/cloudposse/terraform-aws-iam-policy/pull/26

New Contributors

• @​gberenice made their first contribution in https://github.com/cloudposse/terraform-aws-iam-policy/pull/26

Full Changelog: cloudposse/terraform-aws-iam-policy@0.4.0...1.0.0

v0.5.0

Compare Source

Add conditions @​nitrocode (#​19)

what

• Add conditions

why

• Full example

references

• Closes https://github.com/cloudposse/terraform-aws-iam-policy/issues/18
• Closes https://github.com/cloudposse/terraform-aws-iam-policy/pull/17

---

v0.8.1 Update dependencies

🚀 Enhancements

Update dependencies, add testing @Nuru (#40)

what

• Update dependencies
• Add basic testing

why

• Bring in new features and bug fixes. In particular, check aud field of OIDC assertion for EKS IRSA "assume role".
• Because of the nature of this module, it did not have the testing Cloud Posse wants all modules to undergo. Although the testing added in this module is minimal, it does validate that the module is able to deploy a Helm chart without obvious errors, which is better than nothing.

references

• https://github.com/cloudposse/terraform-aws-eks-iam-role/releases/tag/2.0.0
• Closes #15
• Supersedes and closes #16
• Supersedes and closes #35
• Supersedes and closes #39

notes

Using aws-node-termination-handler as the test deployment was not my idea, it was mostly set up by the pre-existing code. A better test would allow for functional testing that everything installed is working correctly, but that would take significantly more time to implement.

Sync github @max-lobur (#38)

Rebuild github dir from the template

v0.8.0

• No changes

v0.7.0 Now requires Kubernetes provider

Add full namespace support @Nuru (#34)

Possibly Breaking Change

This release now requires that you provision a Kubernetes provider as well as a Helm provider. If you were not already doing this, you can do it by copying the kubernetes section of your helm provider configuration and making it your kubernetes provider configuration:

You have:

provider "helm" {
  kubernetes {
   #### whatever Kubernetes configuration you have ####
  }
}

You add:

provider "kubernetes" {
  #### whatever Kubernetes configuration you have ####
}

what

• Provide control over Kubernetes namespace configuration and lifecycle
• Ensure created IAM role is preserved while resources are being cleaned up

why

• Previously, you were not able to add annotations or labels to namespaces
• Namespaces created by this module are now deleted when this module was deleted, previously they were left abandoned, possibly containing abandoned resources
• Previously, the IAM role the deployed service was using to clean up resources could have been deleted before the resource was done cleaning up, causing delays and errors during the terraform destroy process and possibly leaving abandoned AWS resources such as load balancers.