Participants
Damien Duportal (@dduportal ), Hervé Le Meur (@hlemeur ), Mark Waite (@MarkEWaite ), Stephane Merle, Etienne Studer of Gradle Enterprise (Guest)
Official minutes on GitHub.
Notes
-
Accelerating ci.jenkins.io build and test with Gradle Enterprise - @MarkEWaite
- Etienne Studer of Gradle Enterprise to discuss infrastructure needs
- Concepts
- Reducing time to evaluate a change
- Reducing time to complete a fix
- Reduce failures related to duplicate work
- Collects information from builds and tests while they are running
- Can be done for local builds and CI builds
- More than log capture and log analysis
- Root cause analysis use deeper insights
- Improve collaboration between people assessing issues
- CI issue investigation possible without requiring infra team
- A new dependency pulled into the build
- Smaller issues can be addressed efficiently
- Build scan that captures details about the build
- xwiki example to see dependencies and shareable analysis
- Example available publicly
- xwiki example to see dependencies and shareable analysis
- Faster feedback cycles, CI and locally
- Faster build improves many different areas
- Reduce overhead for new contributors (faster startup)
- Spring boot example - don’t do work we’ve done already
- Reduced spring boot build from 40 minutes to 2 minutes
- Reduce CI resource use
- Skip goals because results are already cached
- Skip tests that are unaffected by the change
- Faster local builds create less demand on CI build
- Fast local build instead of “let CI check it”
- Reduce the rerun pattern with fewer flaky builds
- Spring boot build reports flaky tests to show most flaky
- Shows expensive tests and intermittent failing tests
- CI pushes to the cache, while developers only read from cache
- A pull and build can use the cache
- Caching at the goal level for maven builds
- Predictive test selection (pre-release)
- Preview released this week, not yet production
- Uses historic data rather than code traversal
- Deployment
- Deploys into a Kubernetes cluster
- Supports external database
- Multiple cache nodes and pre-emptive replication allowed
- Configuring a project to use it
- Add extensions.xml with Gradle Enterprise maven extension
- extensions.xml
- gradle-enterprise.xml
- Build cache credentials added to CI to push to cache
- Add extensions.xml with Gradle Enterprise maven extension
- Concepts
- Infrastructure team assess experiment plan, assess impact
- 30 day GE trial process
- Install and configure
- Connect a build
- Capture a baseline
- Optimize performance
- Quantify improvement
- Present return on investment
- Visualizations that show build cache use and build performance
- Detect flaky builds
- How to do it?
- ge.jenkins.io prototype
- 142 goals in 6 projects - 72 minutes
- 142 goals in 6 projects - 2 minutes cached
- ge.jenkins.io prototype
- Credentials on ci.jenkins.io considered compromised
- Would we need to generate the cache elsewhere (staged)?
- Will we get the same benefit from staged cache?
- Benefit from local cache in all cases
- Remote cache with less frequent publishing less benefit
- May need two caches, one on AWS, one on Azure
- Comparing cost of maintaining service vs. paying build?
- Don’t have cost estimates, used on AWS at their accounts
- Costs are not so large for difference between them
- Cache overhead much less than build/test cost
- GE hosts 13 open source instances themselves
- $130 per instance per month
- Kubernetes cluster that hosts our services on one provider
- Local cache possible? - yes
- Kubernetes cluster that hosts ephemeral agents
- Local cache possible? - yes
- Can specific artifacts be removed from cache? - yes
- Sometimes we have 0 byte artifacts written to cache
- Cache key of the entry is available
- Ask to delete the key from all nodes
- 30 day GE trial process
- Mark begin the conversations with governance board and developers
- Mark schedule a developer online meetup to share the experience
- Etienne present to the meetup
- Mark to schedule with Etienne
- Etienne Studer of Gradle Enterprise to discuss infrastructure needs
-
Log4Shell - CVE-2021-44228
- Thanks to Herve, Mark for infrastructure work on CVE
- Accounts.jenkins.io: put it back
- Which additional measures (java version, java opts, log4j)?
- Replace account.jenkins.io by admin/beta (e.g. keycloak)
- What is left to do?
- Log in - Jenkins Jira ?
- Loading...
- Others?
- Running inside a Docker container (jetty:jre8)
- https://github.com/jenkins-infra/account-app/blob/ca55e34578e56a3561a46893fa01dae615e0b8d4/Dockerfile#L1
- Running jdk 8u232 inside accounts.jenkins.io
- Stephane run the Docker scan of beta.accounts.jenkins.io
- Mark run the Docker scan of accounts.jenkins.io
- Read the tag defined on the chart image
- Confirm the SHA checksum matches described pod
- jenkinsciinfra/account-app:169-buildca55e3
- The docker scan listed 6 known issues
- None of them were log4j2
- Confirmed SHA from kubernetes matches pulled SHA
- The docker scan listed 6 known issues
- https://github.com/jenkins-infra/account-app/blob/ca55e34578e56a3561a46893fa01dae615e0b8d4/Dockerfile#L1
- What is left to do?
- Applications are running currently, without ingress
- Account-app:
- https://accounts.jenkins.io no ingress
- Keycloak:
- Keycloak isn’t vulnerable to CVE-2021-44228
- https://beta.accounts.jenkins no ingress
- https://admin.accounts.jenkins.io ingress through private VPN
- Account-app:
- Additional mitigation measures
- Kubernetes scanning?
- Kubernetes Ingress rule + Apache rule to forbid requests with the infamous JNDI in headers and URLs?
- deny listing by words might be complicated: GitHub - Puliczek/CVE-2021-44228-PoC-log4j-bypass-words: 🐱💻 ✂️ 🤬 CVE-2021-44228 - LOG4J Java exploit - WAF bypass tricks
- most of the headers are vulnerables (source with mitigations instructions):
Request headers include but are not limited to X-Api-Version, User-Agent, Cookie, Referer, Accept-Language, Accept-Encoding, Upgrade-Insecure-Requests, Accept, Origin, Pragma, and Content-Type. Note that some public PoC exploit scripts send payload in only the X-Api-Version header, but other headers can be used for exploitation.
- not worth the effort to implement header checks
- Others?
- From /blog/2021/12/microsofts-response-to-cve-2021-44228-apache-log4j2/
Kubernetes administrators may use “kubectl set env” to set the LOG4J_FORMAT_MSG_NO_LOOKUPS=“true” environment variable to apply the mitigation across Kubernetes clusters where the Java applications are running Log4j 2.10 to 2.14.1, effectively reflecting on all pods and containers automatically.
- Not valuable since we’ve not found log4j2 in any images
- From /blog/2021/12/microsofts-response-to-cve-2021-44228-apache-log4j2/
- Team agrees that accounts.jenkins.io and beta.accounts.jenkins.io
- Ask security team for their agreement
- Not ready to bring online until tomorrow