Code Changes for Updates📜
Elastic/Kibana is a Big Bang built/maintained chart. The below details the steps required to update to a new version of the package.
-
Ensure that newest elastic/kibana images are compatible. If possible the image tags should be the same, although patch version differences are OK.
-
Checkout the
renovate/ironbank
branch. This branch should already have the updates you need for the images,elasticsearch.version
,kibana.version
andappVersion
inChart.yaml
. Validate that theversion
values are equal to their respectiveimage.tag
value and that theappVersion
is equal to the elasticsearch version. -
Modify the
version
inChart.yaml
. Since this is an upstream chart you should bump the versioning following semver, and append-bb.0
. In general for new elastic/kibana versions this will mean bumping the minor version (i.e.0.1.2-bb.0
to0.2.0-bb.0
). This value is usually updated automatically by renovate bot. -
Update
CHANGELOG.md
adding an entry for the new version and noting all changes (at minimum should includeUpdated Elastic/Kibana to x.x.x
). -
Generate the
README.md
updates by following the guide in gluon. Renovate bot may have already performed this step for you as well! 🤖 -
If this is a new minor version of Elastic you will likely need to add a new section to
chart/templates/bigbang/upgrade-job.yaml
for the new version upgrade. Follow the existing examples to update the job to support upgrades between old version -> new version. -
Push up your changes, validate that CI passes. If there are any failures follow the information in the pipeline to make the necessary updates and reach out to the team if needed.
-
Perform the steps below for manual testing. CI provides a good set of basic smoke tests but it is beneficial to run some additional checks.
Manual Testing for Updates📜
NOTE: For these testing steps it is good to do them on both a clean install and an upgrade. For clean install, point logging to your branch. For an upgrade do an install with logging pointing to the latest tag, then perform a helm upgrade with logging pointing to your branch.
You will want to install with: - Logging (elastic, eck operator, and fluentbit), and Istio packages enabled - Istio enabled - Dev SSO values for Logging
Testing Steps:
- Ensure all pods go to running (NOTE: this is especially important for the upgrade testing since Big Bang has an “auto rolling upgrade” job in place)
- Login to Kibana without SSO, using the password in the logging-ek-es-elastic-user
secret and username elastic
- Navigate to https://kibana.bigbang.dev/app/management/security/role_mappings and add a role mapping for SSO logins (name: sso, roles: superuser, mapping rules: username=*)
- Logout and attempt to perform an SSO login with your login.dso.mil credentials
- Navigate to https://kibana.bigbang.dev/app/management/kibana/indexPatterns and add any index pattern to test (ex: logstash-*
)
- Navigate to Analytics
-> Discover
and validate that pod logs are appearing in the logstash
index pattern
When in doubt with any testing or upgrade steps ask one of the CODEOWNERS for assistance.
automountServiceAccountToken📜
The mutating Kyverno policy named update-automountserviceaccounttokens
is leveraged to harden all ServiceAccounts in this package with automountServiceAccountToken: false
. This policy is configured by namespace in the Big Bang umbrella chart repository at chart/templates/kyverno-policies/values.yaml.
This policy revokes access to the K8s API for Pods utilizing said ServiceAccounts. If a Pod truly requires access to the K8s API (for app functionality), the Pod is added to the pods:
array of the same mutating policy. This grants the Pod access to the API, and creates a Kyverno PolicyException to prevent an alert.