#spinnaker — Public Fediverse posts on home.social

Can Artuc @[email protected] · 2026-04-21 · 12:55 UTC

Spinnaker, the open-source continuous delivery platform from Netflix and Google, patched CVE-2026-32613, a CVSS 9.9 remote code execution in the Echo notification service. Echo did not restrict its Spring Expression Language context to trusted classes, giving attackers full Java process access. Maintainers back-ported across four branches (2026.1.0, 2026.0.1, 2025.4.2, 2025.3.2). Quality is what maintainers do the week a critical hits an old branch.

#OpenSource #DevOps #CyberSec #Spinnaker

#opensource #devops #cybersec #spinnaker

Can Artuc @[email protected] · 2026-04-21 · 12:55 UTC

Spinnaker, the open-source continuous delivery platform from Netflix and Google, patched CVE-2026-32613, a CVSS 9.9 remote code execution in the Echo notification service. Echo did not restrict its Spring Expression Language context to trusted classes, giving attackers full Java process access. Maintainers back-ported across four branches (2026.1.0, 2026.0.1, 2025.4.2, 2025.3.2). Quality is what maintainers do the week a critical hits an old branch.

#OpenSource #DevOps #CyberSec #Spinnaker

#opensource #devops #cybersec #spinnaker

ДевоПес @[email protected] · 2026-03-21 · 09:41 UTC

Учора до ночі провозився з #clouddriver від #Spinnaker: це компонент, який відповідає за опрос стану хмарних сервісів (Kubernetes кластера, Docker регістрі). Под почав крашитись після перевода на нову #EKS ноду та вижирати доступні CPU ресурси.
Раніше я виявив, що така поведінка через накопичення команд опросу EKS кластерів та Docker регістрі. Справа у тому, що для обох процесів треба отрмати #AWS токени.
Для EKS це була команда:
```
aws eks get-token --cluster-name XXX --output json
```
Але в поді іноді її виконання займало до 10 секунд. AWS CLI написаний на #Python, тому працює повільно. Заміним цю команду на aws-iam-authenticator, який написаний на #Go та працює в 5-6 разів швидше:
```
aws-iam-authenticator token -i XXX
```
Наступна проблема з #Docker. Команда автентифікації була
```
aws ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken' | base64 -d | sed 's/^AWS://'
```
Ця команда теж іноді по 10-15 секунд виконувалась та віджирала CPU. Токен дійсний на 12 годин, але опрос запускається кожні 5 хвилин, тому є сенс кеширувати його. Вигадав таку команду, не лякайтесь ;-) Її треба було саме однорядкову, тому що вона буде додана в #YAML конфіг #Spinnaker:
```
[ ! -f /tmp/ecr-token ] || \
[ $(( $(date +%s) - $(date +%s -r /tmp/ecr-token) )) -gt 36000 ] \
&& aws ecr get-authorization-token --output text \
--query "authorizationData[].authorizationToken" | \
base64 -d | sed "s/^AWS://" > /tmp/ecr-token; \
cat /tmp/ecr-token
```
Вона перевіряє наявність файла, якщо нема кешированого токена створює його та оновлює його якщо він старий, після просто видає його.
Після цього команди перестали накопичуватись на навантаження на под значнно впало.
Ліг спати щасливий як ніколи ;-)
#devops #troubleshooting

#clouddriver #spinnaker #eks #aws #python #go

ДевоПес @[email protected] · 2026-03-21 · 09:41 UTC

Учора до ночі провозився з #clouddriver від #Spinnaker: це компонент, який відповідає за опрос стану хмарних сервісів (Kubernetes кластера, Docker регістрі). Под почав крашитись після перевода на нову #EKS ноду та вижирати доступні CPU ресурси.
Раніше я виявив, що така поведінка через накопичення команд опросу EKS кластерів та Docker регістрі. Справа у тому, що для обох процесів треба отрмати #AWS токени.
Для EKS це була команда:
```
aws eks get-token --cluster-name XXX --output json
```
Але в поді іноді її виконання займало до 10 секунд. AWS CLI написаний на #Python, тому працює повільно. Заміним цю команду на aws-iam-authenticator, який написаний на #Go та працює в 5-6 разів швидше:
```
aws-iam-authenticator token -i XXX
```
Наступна проблема з #Docker. Команда автентифікації була
```
aws ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken' | base64 -d | sed 's/^AWS://'
```
Ця команда теж іноді по 10-15 секунд виконувалась та віджирала CPU. Токен дійсний на 12 годин, але опрос запускається кожні 5 хвилин, тому є сенс кеширувати його. Вигадав таку команду, не лякайтесь ;-) Її треба було саме однорядкову, тому що вона буде додана в #YAML конфіг #Spinnaker:
```
[ ! -f /tmp/ecr-token ] || \
[ $(( $(date +%s) - $(date +%s -r /tmp/ecr-token) )) -gt 36000 ] \
&& aws ecr get-authorization-token --output text \
--query "authorizationData[].authorizationToken" | \
base64 -d | sed "s/^AWS://" > /tmp/ecr-token; \
cat /tmp/ecr-token
```
Вона перевіряє наявність файла, якщо нема кешированого токена створює його та оновлює його якщо він старий, після просто видає його.
Після цього команди перестали накопичуватись на навантаження на под значнно впало.
Ліг спати щасливий як ніколи ;-)
#devops #troubleshooting

#clouddriver #spinnaker #eks #aws #python #go

ДевоПес @[email protected] · 2026-03-21 · 09:41 UTC

Учора до ночі провозився з #clouddriver від #Spinnaker: це компонент, який відповідає за опрос стану хмарних сервісів (Kubernetes кластера, Docker регістрі). Под почав крашитись після перевода на нову #EKS ноду та вижирати доступні CPU ресурси.
Раніше я виявив, що така поведінка через накопичення команд опросу EKS кластерів та Docker регістрі. Справа у тому, що для обох процесів треба отрмати #AWS токени.
Для EKS це була команда:
```
aws eks get-token --cluster-name XXX --output json
```
Але в поді іноді її виконання займало до 10 секунд. AWS CLI написаний на #Python, тому працює повільно. Заміним цю команду на aws-iam-authenticator, який написаний на #Go та працює в 5-6 разів швидше:
```
aws-iam-authenticator token -i XXX
```
Наступна проблема з #Docker. Команда автентифікації була
```
aws ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken' | base64 -d | sed 's/^AWS://'
```
Ця команда теж іноді по 10-15 секунд виконувалась та віджирала CPU. Токен дійсний на 12 годин, але опрос запускається кожні 5 хвилин, тому є сенс кеширувати його. Вигадав таку команду, не лякайтесь ;-) Її треба було саме однорядкову, тому що вона буде додана в #YAML конфіг #Spinnaker:
```
[ ! -f /tmp/ecr-token ] || \
[ $(( $(date +%s) - $(date +%s -r /tmp/ecr-token) )) -gt 36000 ] \
&& aws ecr get-authorization-token --output text \
--query "authorizationData[].authorizationToken" | \
base64 -d | sed "s/^AWS://" > /tmp/ecr-token; \
cat /tmp/ecr-token
```
Вона перевіряє наявність файла, якщо нема кешированого токена створює його та оновлює його якщо він старий, після просто видає його.
Після цього команди перестали накопичуватись на навантаження на под значнно впало.
Ліг спати щасливий як ніколи ;-)
#devops #troubleshooting

#troubleshooting #devops #yaml #docker #go #python

ДевоПес @[email protected] · 2026-03-21 · 09:41 UTC

Учора до ночі провозився з #clouddriver від #Spinnaker: це компонент, який відповідає за опрос стану хмарних сервісів (Kubernetes кластера, Docker регістрі). Под почав крашитись після перевода на нову #EKS ноду та вижирати доступні CPU ресурси.
Раніше я виявив, що така поведінка через накопичення команд опросу EKS кластерів та Docker регістрі. Справа у тому, що для обох процесів треба отрмати #AWS токени.
Для EKS це була команда:
```
aws eks get-token --cluster-name XXX --output json
```
Але в поді іноді її виконання займало до 10 секунд. AWS CLI написаний на #Python, тому працює повільно. Заміним цю команду на aws-iam-authenticator, який написаний на #Go та працює в 5-6 разів швидше:
```
aws-iam-authenticator token -i XXX
```
Наступна проблема з #Docker. Команда автентифікації була
```
aws ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken' | base64 -d | sed 's/^AWS://'
```
Ця команда теж іноді по 10-15 секунд виконувалась та віджирала CPU. Токен дійсний на 12 годин, але опрос запускається кожні 5 хвилин, тому є сенс кеширувати його. Вигадав таку команду, не лякайтесь ;-) Її треба було саме однорядкову, тому що вона буде додана в #YAML конфіг #Spinnaker:
```
[ ! -f /tmp/ecr-token ] || \
[ $(( $(date +%s) - $(date +%s -r /tmp/ecr-token) )) -gt 36000 ] \
&& aws ecr get-authorization-token --output text \
--query "authorizationData[].authorizationToken" | \
base64 -d | sed "s/^AWS://" > /tmp/ecr-token; \
cat /tmp/ecr-token
```
Вона перевіряє наявність файла, якщо нема кешированого токена створює його та оновлює його якщо він старий, після просто видає його.
Після цього команди перестали накопичуватись на навантаження на под значнно впало.
Ліг спати щасливий як ніколи ;-)
#devops #troubleshooting

#clouddriver #spinnaker #eks #aws #python #go

OffSequence @[email protected] · 2026-03-18 · 01:30 UTC

🚨 CRITICAL: CVE-2026-25534 SSRF in Spinnaker clouddriver-artifacts. Versions <2025.2.4 & select 2025.x allow SSRF via URL validation bypass. Patch to 2025.2.4+, 2025.3.1, 2025.4.1, or 2026.0.0 ASAP! Details: https://radar.offseq.com/threat/cve-2026-25534-cwe-918-server-side-request-forgery-618622b4 #OffSeq #SSRF #Spinnaker

#offseq #ssrf #spinnaker

OffSequence @[email protected] · 2026-03-18 · 01:30 UTC

🚨 CRITICAL: CVE-2026-25534 SSRF in Spinnaker clouddriver-artifacts. Versions <2025.2.4 & select 2025.x allow SSRF via URL validation bypass. Patch to 2025.2.4+, 2025.3.1, 2025.4.1, or 2026.0.0 ASAP! Details: https://radar.offseq.com/threat/cve-2026-25534-cwe-918-server-side-request-forgery-618622b4 #OffSeq #SSRF #Spinnaker

#offseq #ssrf #spinnaker

OffSequence @[email protected] · 2026-03-18 · 01:30 UTC

🚨 CRITICAL: CVE-2026-25534 SSRF in Spinnaker clouddriver-artifacts. Versions <2025.2.4 & select 2025.x allow SSRF via URL validation bypass. Patch to 2025.2.4+, 2025.3.1, 2025.4.1, or 2026.0.0 ASAP! Details: https://radar.offseq.com/threat/cve-2026-25534-cwe-918-server-side-request-forgery-618622b4 #OffSeq #SSRF #Spinnaker

#spinnaker #ssrf #offseq

OffSequence @[email protected] · 2026-03-18 · 01:30 UTC

🚨 CRITICAL: CVE-2026-25534 SSRF in Spinnaker clouddriver-artifacts. Versions <2025.2.4 & select 2025.x allow SSRF via URL validation bypass. Patch to 2025.2.4+, 2025.3.1, 2025.4.1, or 2026.0.0 ASAP! Details: https://radar.offseq.com/threat/cve-2026-25534-cwe-918-server-side-request-forgery-618622b4 #OffSeq #SSRF #Spinnaker

#offseq #ssrf #spinnaker

gturri @[email protected] · 2026-01-27 · 10:51 UTC

Question for devs & ops [1]: what tool are you using for your deployments (and more generally: for your CD) / what open source tools do you recommend?

Context: we're looking into Spinnaker as a candidate to replace our legacy tooling, but some weak signals are giving us the feeling it may not be so active anymore. To get some more data point I'm curious to find out if some of you are using it. And more generally if you have recommendations for that type of tool.

[1]: if you are neither I would still appreciate a boost, for reach 🙏

#devops #spinnaker #argoCD #softwareengineering #software #freesoftware

#devops #spinnaker #argocd #softwareengineering #software #freesoftware