Hurtig opdagelse af lækage af hemmeligheder
Det kan synes at være en lille fejl - at ved et uheld dele legitimationsoplysninger i et offentligt repository. Men konsekvenserne kan være alvorlige. Så snart en hacker får fat i dit kodeord eller API-nøgle, vil de overtage din konto, låse dig ude og misbruge penge. Desuden er der en dominoeffekt: adgang til én konto åbner op for adgang til andre. Indsatsen er høj, så det er ekstremt vigtigt at finde ud af om lækage af hemmeligheder så hurtigt som muligt.
I denne udgivelse præsenterer vi muligheden for som en del af vores SAST-funktionalitet. Hver commit scannes i CI/CD-opgaven for hemmeligheder. Hvis der er en hemmelighed, modtager udvikleren en advarsel i merge-forespørgslen. De kan straks annullere de lækkede legitimationsoplysninger og oprette nye.
Sikring af korrekt ændringsstyring
Som organisationen vokser og bliver mere kompleks, bliver det sværere at opretholde konsistens mellem de forskellige dele af organisationen. Jo flere brugere der er af applikationen, og jo mere indtægt der genereres, jo mere alvorlige er konsekvenserne af at merge forkert eller usikkert kode. For mange organisationer er det en streng nødvendighed at have en korrekt procedure for godkendelse før merging af kode, da risikoen er meget høj.
I GitLab 11.9 er der mere kontrol og en mere effektiv struktur - takket være . Tidligere var det nok at angive en enkelt person eller gruppe (hvor hvert medlem kunne give tilladelse) for at få godkendelse. Nu kan man tilføje flere regler, så en merge-forespørgsel kræver godkendelse fra specifikke personer eller endda fra flere medlemmer af en bestemt gruppe. Derudover er funktionen Code Owners integreret i godkendelsesreglerne, som gør det nemt at identificere den person, der har givet godkendelsen.
Dette giver organisationer mulighed for at implementere komplekse godkendelsesprocesser, mens de stadig bevarer enkelheden i den enkle GitLab-applikation, hvor opgaver, kode, pipelines og overvågningsdata er synlige og tilgængelige til beslutningstagning og acceleration af godkendelsesprocessen.
ChatOps er nu open source
GitLab ChatOps er et effektivt automationsværktøj, der gør det muligt at udføre enhver CI/CD-job og anmode om sin status direkte i chatprogrammer som Slack og Mattermost. , ChatOps var en del af GitLab Ultimate-abonnementet. Baseret på og , flytter vi nogle gange funktioner ned i niveau og aldrig op.
I tilfælde af ChatOps indså vi, at denne funktionalitet kan være nyttig for alle, og at community-deltagelse kan gavne selve funktionen.
I GitLab 11.9 åbnede vi koden for ChatOps Og meget mere!
Der er så mange fantastiske funktioner tilgængelige i denne udgivelse: for eksempel,
Audit af funktionsparametre , og Den mest værdifulde medarbejder (
MVPMarcel Amirault)
har gjort meget Hovedfunktionerne tilføjet i GitLab 11.9
Opdagelse af hemmeligheder og legitimationsoplysninger i forekomsten
(ULTIMATE, GOLD)
Udviklere overfører nogle gange utilsigtet hemmeligheder og legitimationsoplysninger til fjerne lagre. Hvis andre mennesker har adgang til denne kilde, eller hvis projektet er åbent, bliver fortrolige oplysninger afsløret og kan bruges af ondsindede for at få adgang til ressourcer såsom distributionsmiljøer.
GitLab 11.9 har en ny test — “Secret Detection”. Den scanner indholdet af lageret for API-nøgler og andre oplysninger, der ikke bør være her. GitLab viser resultaterne i SAST-rapporten i widgets til merge-requests, pipeline-rapporter og på sikkerhedspaneler.
Hvis du allerede har tilsluttet SAST til din applikation, behøver du ikke gøre noget, bare drag fordel af denne nye funktion. Den er også inkluderet i konfigurationen
Auto DevOps Opgave
(PREMIUM, ULTIMATE, SILVER, GOLD)
(PREMIUM, ULTIMATE, SILVER, GOLD)
Kodereview er en uundgåelig del af hvert succesfuldt projekt, men det er ikke altid klart, hvem der skal stå for review af ændringerne. Ofte er det ønskeligt, at der deltager reviewere fra forskellige teams: udviklingsteamet, brugersupportteamet og produktionsteamet.
Tilladelsesregler forbedrer interaktionen mellem dem, der deltager i kodereview: der defineres et sæt autoriserede godkendere og det minimale antal tilladelser. Tilladelsesreglerne vises i merge-request-widgeten, hvilket gør det muligt hurtigt at udpege den næste reviewer.
I GitLab 11.8 var tilladelsesregler som standard deaktiveret. Fra version 11.9 er de tilgængelige som standard. I GitLab 11.3 introducerede vi muligheden for til at angive teammedlemmer, der er ansvarlige for bestemte kodeområder i projektet. Code Owners-funktionen er integreret i tilladelsesreglerne, hvilket gør det lettere at finde de rigtige personer til at reviewe ændringer.
Flytning af ChatOps til Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Oprindeligt introduceret i GitLab Ultimate 10.6, er ChatOps nu flyttet til GitLab Core. GitLab ChatOps giver mulighed for at køre GitLab CI-job direkt gennem Slack ved hjælp af .
Vi frigiver kildekoden til denne funktion i tråd med vores . Jo oftere den bruges, desto større bidrag vil fællesskabet levere.
Lukning af sårbarheder i merge-requests
(PREMIUM, ULTIMATE, SILVER, GOLD)
Handlinger som at tilføje, fjerne eller ændre funktionsegenskaber bliver nu registreret i GitLab's revisionslog, så du kan se, hvad der er blevet ændret og hvornår. Er der sket en fejl, og du har brug for at tjekke, hvad der er ændret for nylig? Eller skal du blot revidere, hvordan funktionsegenskaberne er blevet ændret? Nu er det meget nemt at gøre.
CI/CD-skabeloner til sikkerhedsopgaver
Udviklere overfører nogle gange utilsigtet hemmeligheder og legitimationsoplysninger til fjerne lagre. Hvis andre mennesker har adgang til denne kilde, eller hvis projektet er åbent, bliver fortrolige oplysninger afsløret og kan bruges af ondsindede for at få adgang til ressourcer såsom distributionsmiljøer.
For hurtigt at håndtere sikkerhedssårbarheder skal processen være simpel. Det er vigtigt at forenkle sikkerhedsrettelser og sætte udviklerne i stand til at fokusere på deres kerneopgaver. I GitLab 11.7 introducerede vi en rettelsesfil , men den skulle downloades, anvendes lokalt og derefter flyttes til det fjerntliggende repository.
I GitLab 11.9 er denne proces automatiseret. Afhjælp sårbarheder uden at forlade GitLab's webgrænseflade. En merge-request oprettes direkte fra sårbarhedsoplysningerne, og denne nye gren vil allerede indeholde en løsning. Efter at have verificeret, at problemet er løst, skal du tilføje rettelsen til hovedgrenen, hvis pipeline er i orden.
Visning af scanningsresultater for containere i gruppens sikkerhedspanel
Udviklere overfører nogle gange utilsigtet hemmeligheder og legitimationsoplysninger til fjerne lagre. Hvis andre mennesker har adgang til denne kilde, eller hvis projektet er åbent, bliver fortrolige oplysninger afsløret og kan bruges af ondsindede for at få adgang til ressourcer såsom distributionsmiljøer.
Gruppens sikkerhedspanel giver specialister mulighed for at fokusere på de mest vigtige arbejdsspørgsmål ved at give et klart og detaljeret overblik over alle potentielle sårbarheder, der kan påvirke applikationer. Derfor er det vigtigt, at panelet indeholder al nødvendig information ét sted og giver brugerne mulighed for at udforske dataene grundigt, inden de fjerner sårbarheder.
I GitLab 11.9 er resultaterne af container-scanning blevet tilføjet til instrumentbrættet, ud over de eksisterende SAST- og afhængighedsscanningsresultater. Nu er hele oversigten samlet ét sted, uanset problemmets kilde.
, — som vi ikke kan vente med at fortælle om!
Udviklere overfører nogle gange utilsigtet hemmeligheder og legitimationsoplysninger til fjerne lagre. Hvis andre mennesker har adgang til denne kilde, eller hvis projektet er åbent, bliver fortrolige oplysninger afsløret og kan bruges af ondsindede for at få adgang til ressourcer såsom distributionsmiljøer.
GitLabs sikkerhedsfunktioner udvikler sig hurtigt og kræver konstant opdateringer for at opretholde effektivitet og beskyttelse af koden. At ændre jobdefinitionen er kompliceret, når man håndterer flere projekter. Og vi forstår også: Ingen ønsker at tage risikoen ved at bruge den nyeste version af GitLab uden at være sikker på dens fulde kompatibilitet med den nuværende GitLab-instans.
Netop af den grund præsenterede vi i GitLab 11.7 en ny mekanisme til jobdefinition ved hjælp af .
Fra GitLab 11.9 vil vi tilbyde indbyggede skabeloner til alle sikkerhedsjob: for eksempel sast og dependency_scanning, der er kompatible med den relevante version af GitLab.
Inkluder dem direkte i din konfiguration, og de vil opdateres sammen med systemet ved hver opdatering til den nye version af GitLab. Pipelinekonfigurationerne forbliver uændrede.
Den nye metode til at definere sikkerhedsjob er officiel og understøtter ikke tidligere jobdefinitioner eller kodefragmenter. Jobdefinitionen bør opdateres så hurtigt som muligt for at bruge det nye nøgleord
template. Understøttelse af enhver anden syntaks kan blive fjernet i GitLab 12.0 eller i andre fremtidige udgivelser.
Andre forbedringer i GitLab 11.9
Svar på kommentar
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab har diskussioner om emner. Tidligere skulle brugeren, der skrev den oprindelige kommentar, fra starten af beslutte, om de ønskede en diskussion.
Vi har lempet denne begrænsning. Tag en hvilken som helst kommentar i GitLab (for opgaver, merge-requests og epics) og svar på den, og dermed starter du diskussionen. På denne måde interagerer teams mere organiseret.
Projekt skabeloner til .NET, Go, iOS og Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
For at gøre det lettere for brugerne at oprette nye projekter, tilbyder vi flere nye projektskabeloner:
- Start , som omfatter en grundlæggende applikation med CI.
- En klar til brug skabelon, der kombinerer og GitLab CI/CD.
- , klar til grundlæggende tilpasning i GitLab. Bemærk, at da der kræves en dedikeret MacOS runner for at bygge iOS, skal du sørge for at have din egen build-server, hvis du vil bruge den med GitLab CI/CD.
- er konfigureret til at arbejde med Netlify.
Krav om godkendelse af merge-requests fra Code Owners
(PREMIUM, ULTIMATE, SILVER, GOLD)
Det er ikke altid indlysende, hvem der godkender en merge-request.
Nu understøtter GitLab krav om godkendelse af merge-requests, afhængig af hvilke filer anmodningen ændrer, ved hjælp af . Code Owners udnævnes med en fil, der hedder CODEOWNERS, formatet ligner gitattributes.
Understøttelse af automatisk tildeling af Code Owners som ansvarlige for godkendelse af merge-requests blev tilføjet allerede i .
Flytning af filer i Web IDE
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Nu kan du flytte en fil eller mappe fra Web IDE til depotet under en ny sti ved at omdøbe den.
Tags i alfabetisk rækkefølge
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab-tags er utroligt alsidige, og teams finder hele tiden nye anvendelser for dem. Som følge heraf tilføjer brugere ofte mange tags til en opgave, merge-request eller epic.
I GitLab 11.9 har vi gjort brugen af tags en smule lettere. I opgaver, merge-requests og epics er tags, der vises i sidepanelet, sorteret alfabetisk. Dette gælder også for visningen af listen over disse objekter.
Hurtige kommentarer ved filtrering af handlinger på opgaven
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
For nylig introducerede vi en funktion, som giver brugerne mulighed for at filtrere aktivitetsstrømmen efter opgaver, merge-forespørgsler eller epics, hvilket gør det muligt at fokusere kun på kommentarer eller systemmeddelelser. Denne indstilling gemmes for hver bruger i systemet, og det kan ske, at brugeren ikke forstår, at når de ser en opgave flere dage senere, ser de en filtreret strøm. De kan have indtryk af, at det ikke er muligt at efterlade en kommentar.
Vi har forbedret denne interaktion. Nu kan brugerne hurtigt skifte til en tilstand, der gør det muligt at efterlade kommentarer uden at rulle tilbage til toppen af strømmen. Dette gælder for opgaver, merge-forespørgsler og epics.
Ændring af rækkefølgen af underordnede epics
Udviklere overfører nogle gange utilsigtet hemmeligheder og legitimationsoplysninger til fjerne lagre. Hvis andre mennesker har adgang til denne kilde, eller hvis projektet er åbent, bliver fortrolige oplysninger afsløret og kan bruges af ondsindede for at få adgang til ressourcer såsom distributionsmiljøer.
For nylig har vi udgivet , der gør det muligt at bruge epics af epics (udover underordnede opgaver i epics).
Nu kan rækkefølgen af underordnede epics i epics ændres ved simpel træk og slip, ligesom med underordnede opgaver. Hold kan bruge rækkefølgen til at afspejle prioritering eller bestemme rækkefølgen af udførelse af opgaver.
Brugerdefinerede systemmeddelelser i top- og bundtekst online og i e-mail
(CORE, STARTER, PREMIUM, ULTIMATE)
Tidligere tilføjede vi en funktion, der gør brugerdefinerede meddelelser i top- og bundtekst synlige på hver side i GitLab. Den blev varmt modtaget, og hold bruger den til at dele vigtige oplysninger: for eksempel systemmeddelelser, der vedrører deres GitLab-instance.
Vi er glade for at introducere denne funktion i Core, så nu kan endnu flere mennesker bruge den. Desuden giver vi brugerne mulighed for at vælge at vise de samme meddelelser i alle e-mails, der sendes via GitLab, for at sikre konsistens med en anden kontaktpunkt for brugeren med GitLab.
Filter for fortrolige opgaver
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Fortrolige opgaver er et nyttigt værktøj for hold, der gør det muligt at føre lukkede diskussioner om følsomme emner inden for et åbent projekt. Især er de ideelle til at arbejde med sikkerhedsanfald. Indtil nu har det ikke været så let at håndtere fortrolige opgaver.
I GitLab 11.9 er opgavelisten i GitLab nu filtreret efter hemmelige eller ikke-hemmelige opgaver. Dette gælder også for API-søgning af opgaver.
Tak for bidraget fra Robert Schilling ()!
Redigering af domæne i Knative efter implementering
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Angivelse af et brugerdefineret domæne ved installation af Knative muliggør drift af forskellige serverløse applikationer/funktioner med en unik slutpunkt.
Nu tillader Kubernetes-integrationen i GitLab ændring/opdatering af det brugerdefinerede domæne efter deploying af Knative til Kubernetes-klusteret.
Kontrol af formatet på Kubernetes CA-certifikatet
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ved tilføjelse af et eksisterende Kubernetes-kluster, kontrollerer GitLab nu, at det indtastede CA-certifikat har et gyldigt PEM-format. Dette forhindrer mulige fejl med Kubernetes-integrationen.
Udvidelse af sammenligningsværktøjets funktioner til hele filen
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Når du gennemgår ændringerne i en merge request, kan du nu udvide sammenligningsværktøjet for hver fil for at vise hele filen for mere kontekst og efterlade kommentarer i uændrede linjer.
Udførelse af specifikke jobs i merge requests kun ved ændring af bestemte filer
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
I GitLab 11.6 blev muligheden for at definere for pipeline-jobs tilføjet, så brugere kun kan udføre specifikke opgaver, når der oprettes en merge request.
Nu udvider vi denne funktionalitet: Der er tilføjet en logik til at forbinde , og brugere kan udføre specifikke jobs kun for merge requests og kun ved ændring af bestemte filer.
Tak for bidraget fra Hiroyuki Sato ()!
Automatisk overvågning af GitLab med Grafana
(CORE, STARTER, PREMIUM, ULTIMATE)
Grafana er nu inkluderet i vores Omnibus-pakke, hvilket gør det lettere at forstå, hvordan din instans fungerer.
Konfigurer grafana['enable'] = true i gitlab.rb, og Grafana vil være tilgængelig på: https://your.gitlab.instance/-/grafana. Snart introducerer vi også GitLab-dashboards Visning af primære epics i epics-sidepanelet
Vi har for nylig præsenteret
Udviklere overfører nogle gange utilsigtet hemmeligheder og legitimationsoplysninger til fjerne lagre. Hvis andre mennesker har adgang til denne kilde, eller hvis projektet er åbent, bliver fortrolige oplysninger afsløret og kan bruges af ondsindede for at få adgang til ressourcer såsom distributionsmiljøer.
, der muliggør brugen af epics af epics. I GitLab 11.9 har vi forenklet mekanismen til visning af dette forhold. Nu er ikke kun den overordnede epic for en given epic synlig, men hele epics-træet i højre sidepanel. Det kan ses, om disse epics er lukkede eller ej, og man kan endda navigere direkte til dem.
Link til den nye opgave fra en flyttet og lukket opgave
Link til ny opgave fra flyttet og lukket opgave
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
I GitLab kan opgaver nemt flyttes til et andet projekt via sidepanelet eller hurtige handlinger. Bag kulisserne lukkes den eksisterende opgave, og der oprettes en ny opgave i det ønskede projekt med alle de kopierede oplysninger, inklusive systemnoter og attributter fra sidepanelet. Det er en fantastisk funktion.
Når der er en systemnote om flytning, kan brugerne blive forvirrede, når de ser en lukket opgave: de kan ikke undgå at forstå, at opgaven er lukket på grund af flytningen.
I denne udgivelse angiver vi direkte på ikonet i toppen af den lukkede opgave, at den er flyttet, og vi inkluderer et indbygget link til den nye opgave, så alle der besøger den gamle hurtigt kan gå til den nye.
YouTrack integration
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab integrerer med mange eksterne systemer til opgavestyring, hvilket letter for teams at bruge GitLab til andre funktioner, mens de holder fast i deres valgte opgavestyringsværktøj.
I denne udgivelse har vi tilføjet integrationen af YouTrack fra JetBrains.
Vi takker Kotau Yauhen for hans bidrag ()!
Ændring af størrelsen på filtræet i merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Når man ser ændringerne i en merge request, kan man nu ændre størrelsen på filtræet for at vise lange filnavne eller spare plads på små skærme.
Gå til de seneste opgavetavler
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Opgavetavler er meget praktiske, og teams opretter flere tavler for hvert projekt og gruppe. For nylig tilføjede vi en søgetavle for hurtigt at filtrere alle de tavler, du er interesseret i.
I GitLab 11.9 præsenterede vi også sektionen Seneste i dropdown-menuen. På den måde kan man hurtigt gå til de tavler, som man for nylig har interageret med.
Muligheden for udviklere at oprette beskyttede grene
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Beskyttede grene tillader ikke flytning eller merging af ikke-godkendt kode. Men hvis ingen har tilladelse til at flytte beskyttede grene, kan ingen skabe en ny beskyttet gren, for eksempel en release-gren.
I GitLab 11.9 kan udviklere oprette beskyttede grene fra allerede beskyttede grene via GitLab eller API. Brugen af Git til at flytte en ny beskyttet gren er stadig begrænset — for ikke ved et uheld at oprette nye beskyttede grene.
Deduplication af Git-objekter for åbne grene (Beta)
(CORE, STARTER, PREMIUM, ULTIMATE)
Grene gør det muligt for enhver at deltage i open source-projekter: uden skriveadgang, simpelthen ved at kopiere depoten til et nyt projekt. At gemme komplette kopier af ofte grene Git-depoter er ineffektivt. Nu med Git alternativer grene deler fælles objekter fra det overordnede projekt i objektpuljen for at reducere kravene til diskopbevaring.
Objektpuljer for grene oprettes kun for åbne projekter, hvis der er tilsluttet et hash-baseret lager. Objektpuljer aktiveres med funktionen object_pools.
Filtrering af listen over merge-forespørgsler efter tildelte godkendere
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Kodegennemgang er en almindelig praksis for ethvert vellykket projekt, men det kan være vanskeligt for anmeldere at holde styr på merge-forespørgsler.
I GitLab 11.9 filtreres listen over merge-forespørgsler efter den tildelte godkender. På den måde kan du finde merge-forespørgsler, der er tilføjet til dig som anmelder.
Tak for dit bidrag, Glavin Wiechert ()!
Genvejstaster til næste og forrige fil i merge-forespørgslen
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Når du gennemser ændringer i en merge-forespørgsel, kan du hurtigt skifte mellem filer med ]eller j for at gå til næste fil og [ eller k for at gå til den forrige fil.
Forenkling .gitlab-ci.yml for serverless-projekter
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Oprettet baseret på funktionaliteten GitLab CI, serverless-skabelon gitlab-ci.yml er blevet betydeligt forenklet. For at introducere nye funktioner i fremtidige udgivelser er det ikke nødvendigt at ændre denne fil.
Understøttelse af Ingress-værtsnavne
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Under implementeringen af Kubernetes Ingress-controlleren returnerer nogle platforme en IP-adresse (f.eks. GKE fra Google), mens andre returnerer et DNS-navn (f.eks. EKS fra AWS).
Vores Kubernetes-integration understøtter nu begge typer slutpunkter til visning i afsnittet clusters projekt.
Tak for dit bidrag, Aaron Walker ()!
Adgangsbegrænsning til JupyterHub-login kun for gruppe-/projektdeltagere
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Implementering af JupyterHub ved hjælp af GitLab integration med Kubernetes er en fremragende måde at vedligeholde og bruge Jupyter Notebook i store grupper. Det er også nyttigt at kontrollere adgangen til dem ved overførsel af følsomme eller personlige data.
I GitLab 11.9 er adgangen til JupyterHub-forekomster, der er implementeret via Kubernetes, begrænset til projektmedlemmer med "udvikler"-adgangsniveau (via gruppe eller projekt).
Tilpassede tidsrammer for sikkerhedspaneldiagrammer
Udviklere overfører nogle gange utilsigtet hemmeligheder og legitimationsoplysninger til fjerne lagre. Hvis andre mennesker har adgang til denne kilde, eller hvis projektet er åbent, bliver fortrolige oplysninger afsløret og kan bruges af ondsindede for at få adgang til ressourcer såsom distributionsmiljøer.
Sikkerhedsdiagrammet for gruppen inkluderer en sårbarhedsschema til gennemgang af den aktuelle sikkerhedsstatus for gruppens projekter. Dette er meget nyttigt for sikkerhedsdirektører til at tilpasse processer og forstå teamets arbejdsmetode.
I GitLab 11.9 kan du nu vælge tidsrammen for dette sårbarhedsschema. Som standard er det de sidste 90 dage, men du kan indstille et interval til 60 eller 30 dage, afhængigt af det ønskede detaljeringsniveau.
Dette påvirker ikke dataene i tællerne eller listen, kun de datapunkter, der vises på diagrammet.
Tilføjelse af Auto DevOps bygning job til tags
(CORE, STARTER, PREMIUM, ULTIMATE, GRATIS, BRONZE, SILVER, GOLD)
Auto DevOps byggefase opretter en bygning af din applikation ved hjælp af projektets Dockerfile eller Heroku byggetype.
I GitLab 11.9 får det resulterende Docker-billede, der er indbygget i tagpipelinjen, et navn, der ligner traditionelle billednavne ved hjælp af tagget i stedet for SHA-commiten.
Tak for bidraget, Aaron Walker!
Opdatering af Code Climate til version 0.83.0
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab bruger til at kontrollere, hvordan ændringer påvirker tilstanden af din kode og projekt.
I GitLab 11.9 har vi opdateret motoren til den nyeste version (), for at levere fordele ved yderligere sprog og statisk analyseunderstøttelse til GitLab Code Quality.
Tak for bidraget, GitLab Core-teammedlem Takuya Noguchi ()!
Skalering og panoramaer på metrics-panelet
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Når du undersøger ydeevneanomalier, er det ofte nyttigt at tage et nærmere kig på specifikke dele af en bestemt metric.
Med GitLab 11.9 vil brugere kunne skalere individuelle tidsperioder på metrics-panelet, rulle hele tidsintervallet og nemt vende tilbage til visningen af det oprindelige tidsinterval. Dette muliggør hurtig og nem undersøgelse af relevante hændelser.
SAST til TypeScript
Udviklere overfører nogle gange utilsigtet hemmeligheder og legitimationsoplysninger til fjerne lagre. Hvis andre mennesker har adgang til denne kilde, eller hvis projektet er åbent, bliver fortrolige oplysninger afsløret og kan bruges af ondsindede for at få adgang til ressourcer såsom distributionsmiljøer.
er et relativt nyt programmeringssprog baseret på .
I GitLab 11.9 analyserer funktionen Static Application Security Testing (SAST) TypeScript-kode og opdager sårbarheder, og viser dem i merge request-widgeten, på pipeline-niveau og på sikkerhedspanelet. Den nuværende jobdefinition sast skal ikke ændres, og den er også automatisk aktiveret i .
SAST for multimodulære Maven-projekter
Udviklere overfører nogle gange utilsigtet hemmeligheder og legitimationsoplysninger til fjerne lagre. Hvis andre mennesker har adgang til denne kilde, eller hvis projektet er åbent, bliver fortrolige oplysninger afsløret og kan bruges af ondsindede for at få adgang til ressourcer såsom distributionsmiljøer.
Maven-projekter er ofte organiseret til at samle i et enkelt repository. Tidligere kunne GitLab ikke korrekt scanne sådanne projekter, og udviklere og sikkerhedsspecialister modtog ikke sårbarhedsrapporter.
GitLab 11.9 tilbyder avanceret support til SAST-funktionaliteten til denne specifikke projektkonfiguration, hvilket giver mulighed for at teste dem for sårbarheder i deres oprindelige tilstand. Takket være fleksibiliteten i analysatorerne defineres konfigurationen automatisk, og du behøver ikke ændre noget for at se resultaterne for multimodulære Maven-applikationer. Som sædvanligt er lignende forbedringer også tilgængelige i .
GitLab Runner 11.9
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
I dag har vi også udgivet GitLab Runner 11.9! GitLab Runner er et open source-projekt, der bruges til at køre CI/CD-opgaver og sende resultaterne tilbage til GitLab.
Nedenfor er nogle ændringer i GitLab Runner 11.9:
- .
- og .
- . Det inkluderer også .
- for at støtte , som vil være tilgængelige i GitLab 11.10.
- .
- .
- Flytning af flere script — herunder og — til Go.
- .
- .
- .
En komplet liste over ændringer kan findes i changelog for GitLab Runner: .
Forbedringer af GitLab-skemaet
(CORE, STARTER, PREMIUM, ULTIMATE)
Følgende forbedringer er foretaget i GitLab-diagrammet:
- Tilføjet støtte til Google Cloud Memorystore.
- Cron job-indstillinger , da de bruges af flere tjenester.
- Registreringen er opdateret til version 2.7.1.
- En ny parameter er tilføjet, som sikrer, at GitLab-registreringen er kompatibel med Docker-versioner op til 1.10. For at aktivere det, skal du indstille
registry.compatibility.schema1.enabled: true.
Ydelsesforbedring
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Vi fortsætter med at forbedre GitLab's ydeevne med hver udgivelse for GitLab-instanser af enhver størrelse. Her er nogle forbedringer i GitLab 11.9:
- .
- .
- .
- .
Omnibus-forbedringer
(CORE, STARTER, PREMIUM, ULTIMATE)
Følgende Omnibus-forbedringer er inkluderet i GitLab 11.9:
- GitLab 11.9 inkluderer , , som i den seneste udgivelse inkluderer MFA for Team Edition, forbedret ydeevne af billeder og meget mere. Denne version inkluderer også ; opdatering anbefales.
- En ny parameter er tilføjet, som sikrer, at GitLab-registreringen er kompatibel med Docker-versioner op til 1.10. For at aktivere det, skal du indstille
registry['compatibility_schema1_enabled'] = true i gitlab.rb. - GitLab-registreringen eksporterer nu Prometheus-metrics og monitoreres automatisk af den medfølgende .
- Understøttelse af Google Cloud Memorystore er tilføjet, hvilket kræver .
opensslopdateret til version 1.0.2r,nginx— opdateret til version 1.14.2,python— opdateret til version 3.4.9,jemalloc— opdateret til version 5.1.0,docutils— opdateret til version 0.13.1,gitlab-monitor— opdateret til version 3.2.0.
Forældede funktioner
GitLab Geo vil levere hash-baseret lagring i GitLab 12.0
GitLab Geo kræver for at mitigere race condition på sekundære noder. Dette er blevet bemærket i .
I GitLab har vi tilføjet dette krav til Geo-dokumentationen: .
I GitLab sudo gitlab-rake gitlab:geo:check kontrollerer, om hash-lagring er aktiveret, og om alle projekter migreres. Se. . Hvis du bruger Geo, skal du køre denne kontrol og migrere så hurtigt som muligt.
I GitLab permanent deaktiverbart advarsel vil blive vist på siden Admin Area › Geo › Nodes, hvis de førnævnte kontroller ikke er blevet godkendt.
I GitLab Geo vil bruge kravene til hash-lagring. Se. .
Slettedato: 22. juni 2019.
Hipchat-integration
Hipchat . Desuden har vi i version 11.9 .
Slettedato: 22. marts 2019.
Understøttelse af CentOS 6 for GitLab Runner med Docker-executor
GitLab Runner understøtter ikke CentOS 6, når Docker bruges i GitLab 11.9. Dette er et resultat af opdateringen af den underliggende Docker-bibliotek, som ikke længere understøtter CentOS 6. Læs mere i .
Slettedato: 22. marts 2019.
Forældede legacy-stier i GitLab Runner
Fra Gitlab 11.9 bruger GitLab Runner til kloning/kald af repository. I øjeblikket vil GitLab Runner anvende den gamle metode, hvis den nye ikke understøttes.
I GitLab 11.0 ændrede vi synet på metrics server-konfiguration for GitLab Runner. metrics_server vil blive fjernet til fordel for listen_address i GitLab 12.0. Læs mere i . Og flere detaljer i .
I version 11.3 begyndte GitLab Runner at understøtte , hvilket medførte nye indstillinger for . I en tabel over ændringer og instruktioner til overgang til den nye konfiguration. Læs mere i .
Disse stier er ikke længere tilgængelige i GitLab 12.0. Som bruger behøver du ikke at ændre noget, blot sikre dig, at din GitLab-instans kører med version 11.9+ ved opgradering til GitLab Runner 12.0.
Slettedato: 22. juni 2019.
Forældet parameter for feature entry point til GitLab Runner
I 11.4 blev GitLab Runner introduceret med parameteren for at rette sådanne problemer som og .
I GitLab 12.0 vil vi skifte til korrekt opførsel, som om feature-parameteren var deaktiveret. Læs mere i .
Slettedato: 22. juni 2019.
Forældet understøttelse af Linux-distributioner, der har nået EOL, for GitLab Runner
Nogle Linux-distributioner, hvor GitLab Runner kan installeres, er udløbet.
I GitLab 12.0 vil GitLab Runner ikke længere distribuere pakker til sådanne Linux-distributioner. Den fulde liste over distributioner, der ikke længere understøttes, kan findes i vores . Tak til Javier Ardó () for hans !
Slettedato: 22. juni 2019.
Fjernelse af gamle GitLab Runner Helper-kommandoer
Som led i indsatsen for at understøtte blev nogle gamle kommandoer, der bruges til .
I GitLab 12.0 kører GitLab Runner med nye kommandoer. Dette gælder kun brugere, der overstyrer . Læs mere i .
Slettedato: 22. juni 2019.
Udviklere kan slette tags i GitLab 11.10
Sletning eller redigering af versionsnoter for tags i usikrede grene har historisk været begrænset til .
Da udviklerne kan tilføje tags samt ændre og slette ubeskyttede grene, skal udviklerne have mulighed for at slette Git-tags. I GitLab 11.10 i vores tilladelsesmodel for at forbedre arbejdsprocessen og hjælpe udviklerne med bedre og mere effektivt at bruge tags.
Hvis du ønsker at bevare denne begrænsning for medarbejdere og ejere, skal du bruge .
Slettedato: 22. april 2019
Understøttelse af Prometheus 1.x i Omnibus GitLab
Fra GitLab , er den indbyggede version af Prometheus 1.0 udelukket fra Omnibus GitLab. . Men metrikformatet er ikke kompatibelt med version 1.0. Eksisterende versioner kan opgraderes til 2.0 og, hvis nødvendigt, migrere data .
I GitLab-versioner vil Prometheus 2.0 blive installeret automatisk, hvis der ikke er sket nogen opdatering. Data fra Prometheus 1.0 vil gå tabt, da de ikke migreres.
Slettedato: 22. juni 2019.
TLS v1.1
Fra GitLab for at øge sikkerheden. Dette løser en række problemer, herunder Heartbleed, og gør GitLab "out of the box" kompatibel med PCI DSS 3.1-standarden.
For straks at deaktivere TLS v1.1, skal du indstille nginx['ssl_protocols'] = "TLSv1.2" i gitlab.rband og køre gitlab-ctl reconfigure.
Slettedato: 22. juni 2019.
OpenShift-skabelonen til installation af GitLab
Officiel — den anbefalede metode til at køre GitLab på Kubernetes, inklusive .
til installation af GitLab er forældet og vil ikke længere blive understøttet i .
Slettedato: 22. juni 2019.
Tidligere definitioner af sikkerhedsjob
Med introduktionen af bliver alle tidligere jobdefinitioner forældede og vil blive fjernet i GitLab 12.0 eller senere.
Opdater jobdefinitionerne for at bruge den nye syntaks og få glæde af alle de nye sikkerhedsfunktioner, der tilbydes af GitLab.
Dato for fjernelse: 22. juni 2019.
Systeminfo-sektionen i administrationspanelet
GitLab præsenterer oplysninger om din GitLab-instans i admin/system_info, men disse oplysninger kan være unøjagtige.
Vi af administrationspanelet i GitLab 12.0 og anbefaler at bruge .
Slettedato: 22. juni 2019.
Kilde: habr.com
