Skip to main content
SmoothGlue Logo
In this section

v6.5.0

Released: December 30, 2024

6.5.0 (2024-12-30)​

🚨 Upgrade Notices​

If you see a :octagonal_sign: it means that some form of manual step is required to proceed, please heed these warnings.

  • :octagonal_sign: Zarf version required is now v0.36.1 to support new functionality around deploying OCI artifacts. Upgrading existing clusters requires using the new version to zarf init the cluster to upgrade onto the new version
  • :octagonal_sign: Due to a FIPs compliance issue in the Big Bang's version of Gitlab you MUST upgrade the RDS for GitLab from Postgres version 14 to version 16 while staying on the same version of GitLab. It is recommended to upgrade to Postgres 16 before attempting to upgrade via the IaC. Steps to manually upgrade GitLab RDS:
    • Fully backup GitLab and store backup in secure location
    • Scale down GitLab deployments and statefulsets
    • Go to AWS console and find your GitLab instance (ity won't be in a cluster)
    • Click Modify in the top right
    • Change DB engine version to 16.X
    • Scroll to "additional configurations" --> "Database options"
    • Change DB parameter group to default.postgres16
    • Click continue and BE SURE TO SELECT Apply Immediately
      • AWS will take ~10 minutes to upgrade. Please make sure the RDS is done upgrading before proceeding.
    • Now run the IaC for 6.5. The IaC should accept the database engine version 16 and create a new aws_db_parameters with the 16 family
  • :octagonal_sign: The Terraform EKS module and a major change to how roles attach to the Cluster has been implemented.
    • If you encounter an error in the Terragunt/Terraform with the object called aws_eks_access_entry due to the object already existing, you must:
    • terragrunt import 'module.eks.aws_eks_access_entry.this["<Your access entry name In the HCL>"]' <cluster name>:arn:aws:iam::<aws account>:role/ec2/<Role id>
  • :octagonal_sign: This release updates the Terraform module for AWS EKS from major version 19 to 20, which enables support for EKS cluster access entries. We recommend migrating from the aws-auth ConfigMap to cluster access entries, as this will become the preferred authentication mode for EKS clusters moving forward.

    • For a role which was previously defined using the following parameter in the env.hcl:

      aws_auth_roles = [
        {
          rolearn  = "arn:aws:iam::012345678901:role/AWSReservedSSO_AdministratorAccess_0123456789abcdef",
          username = "AWSReservedSSO_AdministratorAccess_0123456789abcdef",
          groups = [
            "system:masters",
          ]
        },
      ]

      The following access entry is equivalent:

      access_entries = {
        admin = {
          principal_arn = "arn:aws:iam::012345678901:role/aws-reserved/sso.amazonaws.com/us-east-2/AWSReservedSSO_AdministratorAccess_0123456789abcdef"
          policy_associations = {
            cluster_admin = {
              policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
              access_scope = {
                type = "cluster"
              }
            }
          }
        }
      }

    • For existing clusters which are migrating to the API_AND_CONFIG_MAP authentication method, an existing access entry for the cluster creator will be exposed during the migration. was previously not visible when using aws-auth ConfigMap, but will become visible when access entry is enabled. If you are defining a cluster access entry for this IAM entity, it must be imported into Terraform using the following command:

      terragrunt import 'module.eks.aws_eks_access_entry.this["<access_entry_key"]' <eks_cluster_name>:<arn_of_iam_entity>

    • By default, the created EKS clusters will enable authentication via both the newly-enabled cluster access entries, as well as the legacy aws-auth ConfigMap.

      • If you are relying upon the aws-auth ConfigMap in an existing cluster, note that due to major version 20 of the EKS module removing the aws-auth functionality from the core of the module, the aws-auth ConfigMap is created using a separate submodule. This means the existing ConfigMap will be re-created during the Terraform apply process, and any users whose permissions are defined only in the aws-auth ConfigMap may temporarily lose access to the cluster until the ConfigMap is re-created. This should be a one-time process.

    • This version adds the following new variables to the eks-cluster Terraform module:

      • authentication_mode: Determines the enabled EKS authentication modes, defaults to (API_AND_CONFIG_MAP).
      • access_entries: A map of the cluster access entries for the cluster, see the example env.hcl for more information.
      • enable_cluster_creator_admin_permissions: Automatically creates a cluster access entry for the identity running the Terraform module. (This should not be set to true if an explicit access entry is being created for this identity).
  • :octagonal_sign: Due to a Big Bang update for Kyverno 1.13.0 that deprecated how cluster policies are generated and the fact that cluster policies are immutable; the old cluster policies must be manually deleted to allow for the same policies to be recreated. If you have your own custom cluster policies that used generate-XYZ please see Upstream Kyverno release notes to ensure that they follow the new standards. https://kyverno.io/blog/2024/10/30/announcing-kyverno-release-1.13/
    • kubectl delete clusterpolicy generate-networkpolicy-imds
    • kubectl delete clusterpolicy generate-private-git-server-secret
  • ❗ In kyverno update to v1.13 they have remove wildcard permissions which allowed Kyverno controllers to view all resources. We have added back in the wildcard permissions for the time being but all users should follow best practices and remove them
  • ❗ The EKS terraform module update will cause a node rotation, this can take a long time depending on your availability settings and terraform might time out until the EKS node group is back into an active state
  • ❗ GitLab HR will succeed but there will be a job that fails called gitlab-gitlab-upgrade-check, you can delete the job as it is just a warning

📦 SmoothGlue Features​

  • iac: enable specifying EKS cluster log types to save to cloudwatch
  • iac: update eks tf module, support eks cluster access entries

⏩ Upgraded Packages​

🐞 Bug Fixes​

  • This fix restores RKE2 functionality (NeuVector is not working), which has been broken since SmoothGlue release 6.2.0.
  • The AWS EFS CSI driver add-on has been locked down to version v2.1.0 for EKS. The latest version v2.1.1 gives EFS mount failure issues with NeuVector, Jira and Confluence.
  • zarf: add deny imds exclusion for aws-efs-csi-driver

❗ Known Issues​

  • There is a chance that the Kiali pod will be stuck in a non functional state, rotate the pod and it should fix itself
  • crossplane-provider-keycloak might be stuck in an unhealthy state, to remedy find the providerrevision.pkg.crossplane.io for the crossplane-provider-keycloak and force delete it so it can be recreated. This is will be for both run and build.

🌐 Compatibility​

  • The packages for this release were built using Zarf v0.36.1.
  • The packages were tested across the following Kubernetes distributions:
    • RKE2: v1.29.8+rke2r1
    • K3s: v1.30.5+k3s1
    • EKS: v1.29.6
  • The following AMI versions were used for testing:
    • RKE2 AMI: smoothglue-rke2-v1.29.8-rke2r1-rocky-8-base-v1.1.1-stig-2024-09-23T08-14-20Z
    • EKS AMI: smoothglue-eks-1.29.6-rocky-8-base-v1.1.1-stig-2024-09-09T08-14-46Z
    • Base AMI: Rocky-8-EC2-LVM-8.10-20240528.0.x86_64

Other Changes​

  • console: deploy chart from OCI artifact (d3f1c74)**