Skip to main content
Version: 6.18.0

Release Notes

6.18.0 (2025-06-27)​

🚨 Upgrade Notices​

  • Big Bang 3.0.0 requires migration to operatorless Istio.
    • Starting with this release, the deprecated istio and istioOperator components cannot be successfully enabled.
    • Ensure that you have migrated all configurations to the istiod and istioGateway components as appropriate, and that you have removed the istio and istioOperator top-level keys from your bigbang-values.yaml and bigbang-secrets.yaml, if applicable.
    • Review the Operatorless Istio Migration Guide for more details.

📦 SmoothGlue Features​

  • This release adds a new instance_storage_mounts input variable to the eks-cluster IaC module to allow any instance storage present on the instance to be automatically formatted and mounted for use.
    • If the instance type has no instance storage available, this input has no effect. See the EKS Config Reference page for information on configuring this variable.
  • The bbctl Big Bang compliance dashboard tool has been added a SmoothGlue platform tool. It is disabled by default.
    • When enabled, the bbctl tool runs periodically and collects certain information regarding cluster configuration and Kyverno policy violations. This data is presented via Grafana dashboards.
    • See the upstream chart for more details.

⏩ Upgraded Packages​

  • SmoothGlue Enterprise v6.18.0 includes Big Bang Version 3.0.0. For more details on the features and updates included in Big Bang 3.0.0, please refer to the Big Bang release notes.
    • See the upgrade notice above regarding the required migration to operatorless Istio.
    • Configuration for Jaeger and Cluster Auditor has been removed from top-level Big Bang umbrella chart, so matching references in the default bigbang-values.yaml have also been removed.
    • Flux CD has been updated to v2.6.1.
  • Crossplane has been updated to v1.20.0. Refer to the Crossplane v1.20.0 Release Notes for full details. Notable changes:
    • Realtime reconciliation is now enabled by default and enables Crossplane to actively watch for changes, potentially speeding up resource reconciliation significantly. The --poll-interval flag no longer has an effect.
    • The default registry for Crossplane packages is now xpkg.crossplane.io (instead of xpkg.upbound.io.) This has no direct effect on SmoothGlue users since SmoothGlue uses hardened containers from registry1.dso.mil.
  • The crossplane-provider-gitlab image has been updated to v0.10.5.
    • This version of crossplane-provider-gitlab allows use of HTTP basic authentication interacting with GitLab. This has implications for the bootstrapping process for GitLab, when no Personal Access Tokens have yet been created.
      • To configure crossplane-provider-gitlab to use HTTP basic authentication:
        • Add the following to the provider-gitlab ProviderConfig: 
          kind: ProviderConfig
          spec:
            credentials:
              method: BasicAuth
              secretRef:
                key: credential
                name: your-secret-name
                namespace: crossplane-system
        • Create the your-secret-name secret in the crossplane-system namespace: 
          kind: Secret
          data:
            credential: <base64-encoded credential>
        • The credential can be generated using a shell command: 
          echo -n '{"username": "your-username", "password": "your-password"}' | base64
      • See the crossplane-provider-gitlab GitHub for more details.

🪲 Bug Fixes​

  • SmoothGlue platform tools which were previously enabled can now be disabled by explicitly setting the relevant Zarf _ENABLED flag to false. (For example, to disable Keycloak, set the KEYCLOAK_ENABLED flag to false.) A Helm keep annotation prevents the platform tools from being disabled inadvertently, but setting the _ENABLED flag now removes this annotation and allows the component to be disabled. This change has no effect is the _ENABLED flag is left blank or is otherwise not set explicitly to false.
  • When using the automatic SSO configuration with custom realms, this release fixes an issue with automatic detection of the custom realm(s).
  • This release fixes an issue where Istio components could not be disabled independently of the MIGRATE_ISTIO flag. This allows the new and deprecated Istio components to be toggled individually.

🌐 Compatibility​

  • The packages for this release were built using Zarf v0.55.6.
  • The packages were tested across the following Kubernetes distributions:
    • RKE2: v1.31.8+rke2r1
    • K3s: v1.32.5+k3s1
    • EKS: v1.31.7
  • The following AMI versions were used for testing:
    • EKS AMI: smoothglue-eks-1.31.7-rocky-8-base-v1.1.1-stig-2025-05-19T08-22-32Z
    • RKE2 AMI: smoothglue-rke2-v1.31.8-rke2r1-rocky-8-base-v1.1.1-stig-2025-05-19T08-22-30Z
    • Base AMI: base-Rocky-8-EC2-LVM-v1.1.1-stig-2025-05-19T0702

🔗 Helpful Links​

6.17.0 (2025-06-10)​

🚨 Upgrade Notices​

  • GitLab has been updated to v18.0. See GitLab's guide to breaking changes for full details. Note particularly:
    • Support for PostgreSQL 15 is removed in GitLab v18.0. (PostgreSQL 16 is configured with our GitLab RDS IaC module, so no action should be necessary if using up-to-date IaC.)
    • The CI_JOB_TOKEN "Limit access from this project" option for has been removed after being deprecated in GitLab v16.0.
  • Values for the upstream Kyverno Helm chart have been refactored, so overrides which were previously defined under .kyverno.values should be moved to .kyverno.values.kyverno instead. The kyvernoPolicies values are not impacted by this change.
  • Values for the upstream Metrics-server Helm chart have been refactored, so overrides which were previously defined under .addons.metricsServer.values should be moved to .addons.metricsServer.values.upstream.
  • IaC: The default_metadata_options.http_tokens variable for the eks-cluster module now defaults to required instead of optional, disabling IMDSv1. This change will cause a node group rotation due to the updated launch template.
    • If IMDSv1 is required, it can be enabled by setting the following in your env.hcl: 
      locals {
        cluster_inputs = {
          default_metadata_options = {
            http_tokens                 = "optional"
            http_put_response_hop_limit = 2
            instance_metadata_tags      = "disabled"
            http_endpoint               = "enabled"
          }
        }
      }

📦 SmoothGlue Features​

  • IaC: The eks-cluster module now supports a new default_bdm_iops input variable, which allows specifying an explicit IOPS value for the default block device mapping without needing to specify an entirely custom block device mapping.

⏩ Upgraded Packages​

  • This release of SmoothGlue Enterprise v6.17.0 includes Big Bang Version 2.54.0. For more details on the features and updates included in Big Bang Version 2.54.0, please refer to the Big Bang release notes.
    • Operatorless Istio is now generally available in Big Bang 2.54.0. Migration from the Istio operator to operatorless Istio will be required prior to Big Bang 3.0.
  • Zarf has been upgraded to v0.55.6 for stability.
  • Confluence has been updated to chart version 2.0.1-bb.1 and image version confluence-node-lts:9.2.5.
  • Jira has been updated to chart version 2.0.1-bb.1 and image version jira-node-lts:10.3.6.

🌐 Compatibility​

  • The packages for this release were built using Zarf v0.55.6.
  • The packages were tested across the following Kubernetes distributions:
    • RKE2: v1.31.8+rke2r1
    • K3s: v1.32.5+k3s1
    • EKS: v1.31.7
  • The following AMI versions were used for testing:
    • EKS AMI: smoothglue-eks-1.31.7-rocky-8-base-v1.1.1-stig-2025-05-19T08-22-32Z
    • RKE2 AMI: smoothglue-rke2-v1.31.8-rke2r1-rocky-8-base-v1.1.1-stig-2025-05-19T08-22-30Z
    • Base AMI: base-Rocky-8-EC2-LVM-v1.1.1-stig-2025-05-19T0702

🔗 Helpful Links​

6.16.0 (2025-05-29)​

🚨 Upgrade Notices​

  • Promtail has been deprecated, disabled by default, and replaced by Alloy.

    • If the user has any custom configurations of Promtail, they can utilize the Grafana Alloy migration utility to assist with the migration from Promtail to Alloy.
      • Follow the appropriate installation instructions to install Grafana Alloy.
      • With an active connection to the cluster containing a Promtail configuration, run:
        • kubectl get secret -n monitoring promtail-promtail -o yaml, or otherwise obtain the configuration from promtail.yaml.
        • Take the decoded contents of the promtail.yaml key and save locally: alloy convert --source-format=promtail --output=alloy.yaml promtail.yaml
        • Update any custom values.yaml references to .alloy.

  • The new variable, create_cloudwatch_log_group , defaults to true. To opt-out of importing and modifying the log group default retention time, set create_cloudwatch_log_group = false

    • ❗ For existing build clusters, it will require the import of the AWS CloudWatch Log Group (implicitly created by AWS) for each of the (typically 8) RDS instances (shown below) before running the Terraform IaC. Otherwise the IaC upgrade will fail.

    • If opting-in, then enter the following import commands for existing build clusters prior to configuring log retention and running the terraform IaC:

      terragrunt --terragrunt-working-dir modules/jira import 'module.rds.aws_cloudwatch_log_group.this["postgresql"]' /aws/rds/cluster/build-'dbIdentifier'-jira/postgresql
      terragrunt --terragrunt-working-dir modules/confluence import 'module.rds.aws_cloudwatch_log_group.this["postgresql"]' /aws/rds/cluster/build-'dbIdentifier'-confluence/postgresql
      terragrunt --terragrunt-working-dir modules/console import 'module.rds.aws_cloudwatch_log_group.this["postgresql"]' /aws/rds/cluster/build-'dbIdentifier'-console/postgresql
      terragrunt --terragrunt-working-dir modules/mattermost import 'module.rds.aws_cloudwatch_log_group.this["postgresql"]' /aws/rds/cluster/build-'dbIdentifier'-mattermost/postgresql
      terragrunt --terragrunt-working-dir modules/keycloak import 'module.rds.aws_cloudwatch_log_group.this["postgresql"]' /aws/rds/cluster/build-'dbIdentifier'-keycloak/postgresql
      terragrunt --terragrunt-working-dir modules/sonarqube import 'module.rds.aws_cloudwatch_log_group.this["postgresql"]' /aws/rds/cluster/build-'dbIdentifier'-sonarqube/postgresql

      # NOTE: The commands below are a bit different than those above.
      terragrunt --terragrunt-working-dir modules/gitlab import 'module.rds[0].module.db_instance.aws_cloudwatch_log_group.this["postgresql"]' /aws/rds/instance/build-'dbIdentifier'-gitlab/postgresql
      terragrunt --terragrunt-working-dir modules/nexus import 'module.rds[0].aws_cloudwatch_log_group.this["postgresql"]' /aws/rds/cluster/build-'dbIdentifier'-nexus/postgresql

  • The Auto SSO feature is now disabled by default. The following config can be added to the zarf-config.yaml file to enable the feature:

    package:
      deploy:
        set:
          AUTO_SSO_ENABLED: "true"

📦 SmoothGlue Features​

  • Promtail has been deprecated, disabled by default, and replaced by Alloy.
  • Kubernetes v1.31.x is officially supported and the default version used to test SmoothGlue on EKS/RKE2. Additional testing is performed for Kubernetes v1.32.x using internal single node instances on K3s.
  • SmoothGlue also now supports new native Istio Helm charts in preparation for the required migration off of Istio Operator. If users would like to test out the automation and new charts before they are required, as well as read about the pre-migration steps and migration concerns, please see the Istio Migration documentation.
  • IaC Version tracking has been added. Objects deployed via the IaC are saved as a variable in the commit_ref_name in the outputs and will show up as a tag on AWS objects with the tag sg:automation:commit-ref-name .
  • A new Terragrunt variable has been added in the HCL to allow setting apply_immediately for RDS modules. Setting this to true will apply Terraform changes to RDS instances to occur during IaC apply instead at scheduled maintenance time; the default remains false .
  • Auto SSO Feature:
    • This feature is now disabled by default. Please see the linked documentation below on how to enable and configure the feature.
    • SmoothGlue Run environments are now supported and new documentation on how to enable/configure the feature is now available.
  • The CloudWatch Log Group retention policy capability has been added for RDS/Aurora.
    • Two new variables, cloudwatch_log_group_retention_in_days and create_cloudwatch_log_group , have been added to application module inputs within the build.hcl file to configure the Aurora/RDS log group retention time, improving log retrieval times, overall system performance, and cost savings. (See upgrade notices for existing build clusters.)
    • The variable create_cloudwatch_log_group is defaulted to true. For existing clusters, see Upgrade Notices. For new clusters, use cloudwatch_log_group_retention_in_days to set retention days per database as seen below:
locals {
  gitlab_inputs = {
    # Adjust as needed, default is 0 days (logs never expire). Valid value for X is one of:
    # [0 1 3 5 7 14 30 60 90 120 150 180 365 400 545 731 1096 1827 2192 2557 2922 3288 3653]
    cloudwatch_log_group_retention_in_days = X

    # Set to false to avoid importing the cloudwatch_log_group for existing build clusters
    # create_cloudwatch_log_group = false
  }
  # Repeat for each module's input
  jira_inputs = {
    cloudwatch_log_group_retention_in_days = X
  }
  confluence_inputs = {...}
  keycloak_inputs = {...}
  mattermost_inputs = {...}
  sonarqube_inputs = {...}
  console_inputs = {...}
  nexus_inputs = {{...}
}
  • Grafana can be enabled with High Availability (HA). This creates multiple Grafana pods managed by an HPA with pod distribution rules and a backing RDS instance. See our docs for more information.
    • To enable Grafana HA, you must turn on the Grafana module, which can be completed by:
      • Setting the locals.grafana_inputs.high_availability to true
      • Setting modules.grafana to true
    • NOTE: Due to how Grafana pods need to communicate with each other to deconflict and de-duplicate, all database IaC features and in-cluster variables must be enabled at once at the Terragrunt level.
    • Grafana HA can be enabled on existing clusters, and maintainers should be aware of the following chart additions when enabling:
---
grafana:
  values:
    headlessService: true
    autoscaling:
      enabled: true
      minReplicas: 2
      maxReplicas: 5
      targetCPU: "60"
      targetMemory: ""
    podDisruptionBudget:
      apiVersion: "policy/v1"
      minAvailable: 1
    grafana.ini:
      database:
        type: postgres
        host: "${db_host}:${db_port}"
        name: grafana
        user: "${db_name}"
      alerting:
        enabled: false
      unified_alerting:
        enabled: true
        ha_peers: monitoring-grafana-headless:9094
        ha_listen_address: ${POD_IP}:9094
        ha_advertise_address: ${POD_IP}:9094
        rule_version_record_limit: "5"
    affinity:
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          - topologyKey: "kubernetes.io/hostname"
            labelSelector:
              matchLabels:
                dont-schedule-with: grafana

⏩ Upgraded Packages​

  • This release of SmoothGlue Enterprise v6.16.0 includes Big Bang Version 2.53.1. For more details on the features and updates included in Big Bang Version 2.53.1, please refer to the Big Bang Release Notes.
  • Confluence: chart bump(@2.0.0-bb.0) version bump confluence-node-lts:9.2.4
  • Jira: chart bump (2.0.0-bb.2)

🐞 Bug Fixes​

  • SmoothGlue now disables the KubeControllerManagerDown and KubeSchedulerDown Prometheus alerts by default for EKS since those components are located on the control-plane, which is managed by AWS and is not accessible from the cluster.

🌐 Compatibility​

  • The packages for this release were built using Zarf v0.54.0.
  • The packages were tested across the following Kubernetes distributions:
    • RKE2: v1.31.8+rke2r1
    • K3s: v1.32.4+k3s1
    • EKS: v1.31.7
  • The following AMI versions were used for testing:
    • RKE2 AMI: smoothglue-rke2-v1.31.8-rke2r1-rocky-8-base-v1.1.1-stig-2025-05-19T08-22-30Z
    • EKS AMI: smoothglue-eks-1.31.7-rocky-8-base-v1.1.1-stig-2025-05-19T08-22-32Z
    • Base AMI: base-Rocky-8-EC2-LVM-v1.1.1-stig-2025-05-19T0702

6.15.0 (2025-05-14)​

🚨 Upgrade Notices​

  • Zarf is being updated to v0.54.0, which is now the minimum supported version. Trying to use an older Zarf version will result in Zarf registry failures on EKS clusters if using IRSA and S3 bucket backing for the registry (which are the default settings).
  • Ensure that you are using the new Zarf init config from the IaC. You will also need to run the Zarf init steps again to update Zarf. See the "Initializing Zarf on SmoothGlue" section in the "SmoothGlue Build/Run Deploy Guide" for more details. The Zarf registry will be unusable between the period from when the IaC is run and when Zarf is re-initialized.
ZARF_CONFIG=infra-iac/outputs/zarf-init-config.yaml zarf init --components git-server --architecture=amd64
  • The Nexus Repository Manager APIs changed impacting the blobstorage and repo jobs. We have temporarily modified the IaC values to disable these jobs and ensure the IaC values are applied, or the Nexus Repository Manager upgrade will fail.
  • You may need to restart the Keycloak pods using kubectl rollout restart statefulset -n keycloak keycloak to ensure that all pods are using the updated Keycloak theme bundled with this SmoothGlue release.

📦 SmoothGlue Features​

  • This release updates the styling and branding of the SmoothGlue Keycloak theme. Notably, the theme now includes a configurable Terms of Use banner, which can be configured on a per-realm basis. This feature is not enabled by default; to configure the Terms of Use banner, follow these steps:
    • Log into Keycloak's admin console and select the realm you wish to modify.
    • Navigate to "Realm Settings" -> "Localization" -> "Realm Overrides".
    • Click the "Add Translation" button to add a translation with the key "termsText". The value should be the text of your Terms of Use banner. This field supports HTML tags.
  • IAM Roles for Service Accounts (IRSA) is now enabled by default for EKS cluster nodes to access the Zarf registry, when backed up by an S3 bucket (by itself, a default setting). This moves away from the IMDSv1 based S3 bucket policy, which was a less secure access method. Existing clusters will transition seamlessly from IMDSv1 to IRSA based Zarf registry access without requiring any user intervention. Zarf has been updated to v0.54.0 to support this.

⏩ Upgraded Packages​

  • This release of SmoothGlue Enterprise v6.15.0 includes Big Bang Version 2.52.0. For more details on the features and updates included in Big Bang Version 2.52.0, please refer to the Big Bang Release Notes.
  • Upgrades the following Big Bang third-party apps:
    • Cert-Manager: 1.17.2
    • Confluence chart: 1.22.7-bb.1
    • Jira chart: 2.0.0-bb.0

🐞 Bug Fixes​

  • Updated the Keycloak theme, which resolved a Javascript error presented on the login page, as well as re-styled the "update password" page, which previously had white text on a white background for the password input field.

❗ Known Issues​

  • You may encounter a scenario following the upgrade or installation where istio-proxy fails to communicate properly with the istiod service. You may observe an error similar to the following:
    • To workaround this issue, restart the istiod Deployment.
2025-05-12T16:58:56.878375Z	warn	ca	ca request failed, starting attempt 4 in 804.379312ms
2025-05-12T16:58:57.683232Z	error	citadelclient	failed to sign CSR: create certificate: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing:

  • The following only applies to the initial deployment of the SmoothGlue IAC. No action is required for updates to already deployed clusters - Due to an upstream issue for the EKS module and when deploying a cluster using an AL2023 AMI, the System Integrator will need to manually generate and set a Zarf registry pull password. The following config can be added to the env.hcl file:

    locals {
      cluster_inputs = {
        zarf_registry_pull_password = "securepassword123"
      }
    }

  • When using a network load balancer (NLB) with the preserve_client_ip option enabled, the default routing rules for EKS nodes prevent nodes from accessing platform services hosted on the same node, which can cause failures when logging into Keycloak, particularly on clusters with fewer nodes.

    • More specifically, the default routing rules for nodes do not route traffic to the VPC router for traffic within the node’s local subnet, since these addresses should theoretically be reachable directly by the node. However, when using the preserve_client_ip option, the VPC router rewrites the source IP for traffic; when the node attempts to talk to the NLB, the traffic is rewritten so that it appears to come from the node itself, and the return traffic is not able to be routed correctly back to the NLB.
    • The following options are potential workarounds:
      • Disabling the preserve_client_ip option on the NLB will resolve the issue at the cost of losing source attribution for incoming traffic.
      • Removing the local subnet route on nodes will resolve the issue at the cost of increasing the amount and cost of traffic being routed through the VPC router.
      • Increasing the node count for the cluster will reduce the likelihood of the issue because it will become less likely for any given traffic to be routed back to the original node.

  • The Big Bang Istio Helm chart has a bug that prevents Istio Gateway deployments from properly being upgraded. During an upgrade, Istio Gateway deployments may get stuck as a result and will need manual intervention to complete the upgrade. To validate the issue in the cluster, check the health of the istiooperators.install.istio.io resource as follows:

    kubectl get istiooperators.install.istio.io -n istio-system

    If it is in Error status, delete all Istio Gateway deployments in the istio-system namespace to allow the Istio Operator to finish reconciling the upgrade and report a Healthy status. The deployments will be recreated automatically by the Istio Operator. For example:

    kubectl delete deployment.apps/admin-ingressgateway -n istio-system
    kubectl delete deployment.apps/passthrough-ingressgateway -n istio-system
    kubectl delete deployment.apps/public-ingressgateway -n istio-system

    Note: Deleting the deployments will entail some brief but non-zero downtime.

    https://repo1.dso.mil/big-bang/product/packages/istio-controlplane/-/issues/253 has been opened to track this issue, which was introduced in SmoothGlue 6.7 (Big Bang 2.44)

🌐 Compatibility​

  • The packages for this release were built using Zarf v0.54.0.
  • The packages were tested across the following Kubernetes distributions:
    • RKE2: v1.30.12+rke2r1
    • K3s: v1.32.3+k3s1
    • EKS: v1.30.9-eks-5d632ec

6.14.1 (2025-05-07)​

Package Bug Fixes​

  • add missing k8s-sidecar image (b2fc23e)

6.14.0 (2025-05-01)​

🚨 Upgrade Notices​

  • Updated Console's default config to change the default Keycloak host config from login.<domain> to keycloak.<domain>. SmoothGlue Build environments use the keycloak.<domain> host by default when deploying Keycloak. If deploying Keycloak under login.<domain> the following can be added to the bigbang-values.yaml to configure Console to use the overwritten host for Keycloak:

    packages:
      console:
        values:
          keycloak:
            host: login.<domain>

  • This upgrade includes a major version update to Keycloak. The full migration guide for Keycloak 26.0.0 is located here. Specific changes of note:

    • If you are currently setting the KC_PROXY environment variable to edge using the .addons.keycloak.values.secrets.env value, note that this option has been removed. It has been replaced by KC_PROXY_HEADERS option, which should be set automatically if the value .addons.keycloak.values.proxy.enabled is set to true.

      addons:
        keycloak:
          values:
            proxy:
              enabled: true

  • Keycloak may fail to upgrade.

    • To resolve this, reconcile the helm release and then delete the pods within the keycloak namespace.
      flux reconcile hr -n bigbang keycloak --with-source --force
      kubectl delete pods -n keycloak
    • Alternately, scale the keycloak pod replica count to 1 by editing the Horizontal Pod Autoscaler before starting the upgrade.
      kubectl patch hpa -n keycloak keycloak  -p "{\"spec\":{\"minReplicas\":1,\"maxReplicas\":1}}"

    And then scale it back up once done with the upgrade, for example.

      kubectl patch hpa -n keycloak keycloak  -p "{\"spec\":{\"minReplicas\":2,\"maxReplicas\":5}}"

  • The SmoothGlue EKS IaC's zarf-config output now includes Zarf variables for AWS and a variable for CLUSTER_NAME. When using the auto-SSO feature, please ensure the variables in the outputted zarf-config are merged with customer-managed zarf-config's to ensure Keycloak client names are configured properly.

📦 SmoothGlue Features​

  • SmoothGlue Automated SSO:
    • SmoothGlue now automatically configures the _structusureAdmins group with the appropriate Keycloak permissions to manage the smoothglue realm.
    • SmoothGlue now automatically configures cluster-level prefixes onto Keycloak clients managed by SmoothGlue. This change will enable future work to allow a SmoothGlue Run's SSO clients to be managed by SmoothGlue. Some applications may need to be manually restarted to pickup the new SSO client names.
    • SmoothGlue now automates the creation of the Keycloak objects for SonarQube. There are still some manual steps required by System Integrators to enable SSO for SonarQube. Please see updated documentation.
    • SmoothGlue will automatically configure a Keycloak client and automatically configure the application for:
      • Gitlab
      • Mattermost
      • Console
    • SmoothGlue will automatically configure a Keycloak client for:
      • Confluence
      • Jira
  • This release updates the styling and branding of the SmoothGlue Keycloak theme. Notably, the theme now includes a configurable terms of use banner which can be configured on a per-realm basis. This feature is not enabled by default; to configure the terms of use banner, follow these steps:
    • Log into Keycloak's admin console and select the realm you wish to modify.
    • Navigate to "Realm Settings" -> "Localization" -> "Realm Overrides".
    • Click the "Add Translation" button to add a translation with the key "termsText". The value should be the text of your Terms of Use banner. This field supports HTML tags.

⏩ Upgraded Packages​

  • This release of SmoothGlue Enterprise v6.14.0 includes Big Bang Version 2.51.0. For more details on the features and updates included in Big Bang Version 2.51.0, please refer to the Big Bang release notes.
    • Kiali stays pinned to the earlier 2.50.0 version of v2.6.0 due to a failure seen in latest version.

🐞 Bug Fixes​

  • Docusaurus and Tailwind config to support dark mode by default. Updated global footer to add a label for the legal links.

❗ Known Issues​

  • The following only applies to the initial deployment of the SmoothGlue IAC. No action is required for updates to already deployed clusters - Due to an upstream issue for the EKS module and when deploying a cluster using an AL2023 AMI, the System Integrator will need to manually generate and set a Zarf registry pull password. The following config can be added to the env.hcl file:

    locals {
      cluster_inputs = {
        zarf_registry_pull_password = "securepassword123"
      }
    }

  • When using a network load balancer (NLB) with the preserve_client_ip option enabled, the default routing rules for EKS nodes prevent nodes from accessing platform services hosted on the same node, which can cause failures when logging into Keycloak, particularly on clusters with fewer nodes.

    • More specifically, the default routing rules for nodes do not route traffic to the VPC router for traffic within the node’s local subnet, since these addresses should theoretically be reachable directly by the node. However, when using the preserve_client_ip option, the VPC router rewrites the source IP for traffic; when the node attempts to talk to the NLB, the traffic is rewritten so that it appears to come from the node itself, and the return traffic is not able to be routed correctly back to the NLB.
    • The following options are potential workarounds:
      • Disabling the preserve_client_ip option on the NLB will resolve the issue at the cost of losing source attribution for incoming traffic.
      • Removing the local subnet route on nodes will resolve the issue at the cost of increasing the amount and cost of traffic being routed through the VPC router.
      • Increasing the node count for the cluster will reduce the likelihood of the issue because it will become less likely for any given traffic to be routed back to the original node.

  • The Big Bang Istio Helm chart has a bug that prevents Istio Gateway deployments from properly being upgraded. During an upgrade, Istio Gateway deployments may get stuck as a result and will need manual intervention to complete the upgrade. To validate the issue in the cluster, check the health of the istiooperators.install.istio.io resource as follows:

    kubectl get istiooperators.install.istio.io -n istio-system

    If it is in Error status, delete all Istio Gateway deployments in the istio-system namespace to allow the Istio Operator to finish reconciling the upgrade and report a Healthy status. The deployments will be recreated automatically by the Istio Operator. For example:

    kubectl delete deployment.apps/admin-ingressgateway -n istio-system
    kubectl delete deployment.apps/passthrough-ingressgateway -n istio-system
    kubectl delete deployment.apps/public-ingressgateway -n istio-system

    Note: Deleting the deployments will entail some brief but non-zero downtime.

    https://repo1.dso.mil/big-bang/product/packages/istio-controlplane/-/issues/253 has been opened to track this issue, which was introduced in SmoothGlue 6.7 (Big Bang 2.44)

🌐 Compatibility​

  • The packages for this release were built using Zarf v0.46.0.
  • The packages were tested across the following Kubernetes distributions:
    • RKE2: v1.30.11+rke2r1
    • K3s: v1.32.3+k3s1
    • EKS: v1.30.9-eks-5d632ec
  • Refer to the SmoothGlue documentation for additional guidance.
  • For details on the Big Bang release, see the Big Bang Release Notes.

6.13.0 (2025-04-16)​

📦 SmoothGlue Features​

  • A new optional variable cloudwatch_log_group_retention_in_days has been added to the env.hcl files to configure the EKS cluster log group retention time. It can be configured as shown below.

    locals {
      cluster_inputs = {
        # Adjust as needed, default is 90 days. Valid value for X is one of:
        # [0 1 3 5 7 14 30 60 90 120 150 180 365 400 545 731 1096 1827 2192 2557 2922 3288 3653]
        cloudwatch_log_group_retention_in_days = X
      }
    }

  • IAM policies generated by the SmoothGlue IAC no longer apply tags to IAM policies when compatibility_mode is set to true. This change is to conform to limitations on high-side deployments

    • NOTE: On an existing cluster, you may need to delete the allow_kms and allow_cluster_autoscaler IAM policies to allow their recreation.

⏩ Upgraded Packages​

  • This release of SmoothGlue Enterprise v6.13.0 includes Big Bang Version 2.50.0. For more details on the features and updates included in Big Bang Version 2.50.0, please refer to the Big Bang release notes.
  • Upgrades the following Big Bang third-party apps:
    • Confluence LTS: 9.2.3
    • Jira LTS: 10.3.5
    • Nexus IQ Server: 1.189.0-01

🐞 Bug Fixes​

  • Fixed an issue that prevented user data scripts from running on AL2023 AMIs.
  • Fixed an issue that overwrote default values from SmoothGlue with customer overrides. This prevented SmoothGlue default values from being viewable at runtime. Overrides provided by customers are still overlayed on top of SmoothGlue default values, so this is a purely cosmetic change.

❗ Known Issues​

  • The following only applies to the initial deployment of the SmoothGlue IAC. No action is required for updates to already deployed clusters - Due to an upstream issue for the EKS module and when deploying a cluster using an AL2023 AMI, the System Integrator will need to manually generate and set a Zarf registry pull password. The following config can be added to the env.hcl file:

    locals {
      cluster_inputs = {
        zarf_registry_pull_password = "securepassword123"
      }
    }

  • When using a network load balancer (NLB) with the preserve_client_ip option enabled, the default routing rules for EKS nodes prevent nodes from accessing platform services hosted on the same node, which can cause failures when logging into Keycloak, particularly on clusters with fewer nodes.

    • More specifically, the default routing rules for nodes do not route traffic to the VPC router for traffic within the node’s local subnet, since these addresses should theoretically be reachable directly by the node. However, when using the preserve_client_ip option, the VPC router rewrites the source IP for traffic; when the node attempts to talk to the NLB, the traffic is rewritten so that it appears to come from the node itself, and the return traffic is not able to be routed correctly back to the NLB.
    • The following options are potential workarounds:
      • Disabling the preserve_client_ip option on the NLB will resolve the issue at the cost of losing source attribution for incoming traffic.
      • Removing the local subnet route on nodes will resolve the issue at the cost of increasing the amount and cost of traffic being routed through the VPC router.
      • Increasing the node count for the cluster will reduce the likelihood of the issue because it will become less likely for any given traffic to be routed back to the original node.

  • The Big Bang Istio Helm chart has a bug that prevents Istio Gateway deployments from properly being upgraded. During an upgrade, Istio Gateway deployments may get stuck as a result and will need manual intervention to complete the upgrade. To validate the issue in the cluster, check the health of the istiooperators.install.istio.io resource as follows:

    kubectl get istiooperators.install.istio.io -n istio-system

    If it is in Error status, delete all Istio Gateway deployments in the istio-system namespace to allow the Istio Operator to finish reconciling the upgrade and report a Healthy status. The deployments will be recreated automatically by the Istio Operator. For example:

    kubectl delete deployment.apps/admin-ingressgateway -n istio-system
    kubectl delete deployment.apps/passthrough-ingressgateway -n istio-system
    kubectl delete deployment.apps/public-ingressgateway -n istio-system

    Note: Deleting the deployments will entail some brief but non-zero downtime.

    https://repo1.dso.mil/big-bang/product/packages/istio-controlplane/-/issues/253 has been opened to track this issue, which was introduced in SmoothGlue 6.7 (Big Bang 2.44)

🌐 Compatibility​

  • The packages for this release were built using Zarf v0.46.0.
  • The packages were tested across the following Kubernetes distributions:
    • RKE2: v1.29.8+rke2r1
    • K3s: v1.32.3+k3s1
    • EKS: v1.30.9-eks-5d632ec