Hvordan bygge avanserte søkeapplikasjoner med hybrid søk: Fordeler og utfordringer

I arbeidet med å utvikle avanserte søkeapplikasjoner er valget mellom tette vektormodeller og spredte vektormodeller sentralt, ettersom de påvirker både ytelse og tilpasningsevne til spesifikke domener. Tette vektormodeller, som krever betydelig finjustering for å tilpasse seg spesialiserte datasett, har fordelen av å levere høy presisjon på tekstbaserte oppgaver som spørsmåls-svar-pair og medisinsk tekst. Imidlertid er det påkrevd å trene modellen på nytt for at den skal fungere optimalt innenfor bestemte domener. I kontrast kan spredte modeller, som benytter teknikker som tekstutvidelse, tilpasse seg forskjellige domener uten behov for omfattende tilpasning.

En god representasjon av denne forskjellen finnes i Elastic Stack, der vi ser på hvordan ELSER, en spredt vektormodell, sammenlignes med tette vektormodeller. ELSER implementerer semantisk søk med minimal tilpasning, og støtter flerspråklighet via E5, mens tette modeller som de som benytter HNSW, krever at vektorene lagres i minnet for å sikre rask søking i sanntid. ELSER, på den annen side, kan bruke tradisjonelle Lucene-indekser, som ikke nødvendigvis krever minnebruk for real-time søk, men har en begrensning på 512 tokens per felt, noe som kan medføre behov for teknikker som chunking ved større datasett.

I tillegg gir ELSER versjon 2 (som er aktuell ved tidspunktet for skriving) støtte for kvantisering, som komprimerer vektorer og sparer minne. Denne teknikken muliggjør bruk av hybride søk, der man kombinerer ELSER’s spredte henteteknikker med tradisjonelle metoder som BM25. Dette åpner for muligheten til å utvikle avanserte søkeapplikasjoner der søkefunksjonalitet kan gi både nøyaktige treff via leksikalsk søk og en dypere forståelse av konteksten i spørringer gjennom semantisk søk.

Den hybride søketeknikken, som kombinerer leksikalsk og vektorbasert søk, gir en grunnlag for videre utvikling innenfor RAG-applikasjoner, hvor det er avgjørende å tilpasse søkefunksjoner etter både exakte nøkkelord og semantiske sammenhenger. Dette gjør at applikasjonen kan hente relevant informasjon ikke bare basert på de nøyaktige ordene i en spørring, men også ved å forstå den bredere betydningen bak spørsmålet. Dette er spesielt nyttig i komplekse domener som medisin, juss og teknisk litteratur, hvor søkene krever at modellen forstår nyanserte betydninger.

Som en del av det videre arbeidet med hybride søk, er det viktig å utforske metoder som score boosting og gjensidig rangering (RRF), som gjør det mulig å justere relevansen mellom de to søkemodellene. I et praktisk scenario kan man justere boost-parametrene for både BM25 og k-NN søk, slik at man får en bedre balanse mellom resultatene fra de to metodene.

En viktig del av utviklingen av søkeapplikasjoner som bruker hybrid søk er å forstå hvordan resultatene fra forskjellige søkemodeller kombineres. Dette innebærer at det kreves en nøye vurdering av hvordan man kan justere vektingen av de ulike resultatene for å få de mest relevante treffene i en brukerorientert applikasjon. Ved å bruke riktig boost-parameter for både BM25 og k-NN, kan man finjustere rangeringen av dokumentene på en måte som reflekterer både de eksakte søkebetingelsene og den semantiske konteksten.

Hvordan definere tilpassede roller for tilgangskontroll i Elastic Stack?

Administrators of Elastic Stack have a critical responsibility to ensure proper access control across various users and roles, maintaining both the security and integrity of the environment. The built-in security roles in Elastic Stack 8 offer a robust framework for managing user access, simplifying the administrative workload, and aligning permissions with compliance standards. However, in many situations, the predefined roles may not offer the exact granularity needed for specific user responsibilities. This is where defining custom roles becomes essential.

Elastic Stack provides administrators with the ability to define custom roles, ensuring precise control over what data users can access and what actions they can perform. This feature allows for an increased level of security and efficiency, crucial for large organizations or environments with specialized needs.

The main advantage of using built-in roles is the ease of administration they offer. With predefined roles, administrators can quickly assign users the appropriate level of access based on their job functions, reducing the chances of misconfigurations or errors. Furthermore, these roles comply with security standards and regulations, providing an automatic audit trail of who has access to what information. However, a limitation of these built-in roles is their rigidity—the set of privileges they provide cannot be modified, which may not suit every use case.

To define custom roles, administrators need to specify the actions that users can take within the Elastic Stack, particularly focusing on what data they can see and interact with. This is important not only for ensuring that the right users have the right access but also for maintaining a structured approach to data governance.

Let’s consider a practical example of creating two custom roles: one for business data access and another for observability data. The first step involves logging into Kibana as an admin user and navigating to the roles section under "Stack Management" and "Security." From there, you can define a custom role by selecting the appropriate indices (e.g., metrics-rennes_traffic-raw) and setting permissions such as "read" and "view_index_metadata." Once the role is created, you can assign it to a new user, ensuring that they only have access to the specified data, such as the Rennes traffic data.

Next, a second role can be created specifically for observability data access. By selecting indices related to metrics, logs, traces, and profiling data (e.g., metrics-kubernetes.*, apm-*), the administrator can grant "read" privileges, ensuring that users with this role can view observability data but not business data. Once these roles are defined and assigned, testing can be performed by logging in with users that have the different roles and verifying their access permissions.

It is important to note that custom roles offer a more granular approach to data security, but this also requires careful planning. Defining too many roles or overly restrictive permissions can complicate management, while overly permissive roles can jeopardize security. Therefore, a balanced approach is crucial to ensure that access rights align with both operational and security requirements.

By combining the flexibility of custom roles with the security of built-in roles, organizations can optimize their access control mechanisms within the Elastic Stack, ensuring that only authorized users can view or manipulate sensitive data. The ability to fine-tune access rights based on roles ensures that administrators have full control over their environments, minimizing the risk of unauthorized access while simplifying user management.

Beyond role definition, administrators should also focus on ensuring that the process of assigning roles is scalable. As organizations grow, the number of users and their corresponding roles can increase rapidly. Using templates and automated systems to manage user onboarding and role assignment can significantly improve efficiency. Additionally, periodic audits should be conducted to review role definitions and ensure they continue to meet security and operational needs.

Finally, although custom roles offer advanced functionality, administrators must remain vigilant about maintaining an overview of their security posture. The defined roles should be regularly reviewed to adapt to changing organizational needs, and any new users should be assigned the least amount of privilege required to perform their job functions. This approach not only minimizes the risk of potential security breaches but also streamlines the administration of a growing user base within the Elastic Stack environment.

Hvordan administrere tilgang med API-nøkler i Kibana og Logstash

I tidligere kapitler har vi lært hvordan man kan administrere tilgangskontroll i Kibana ved bruk av roller. Dette er svært nyttig for interaktiv bruk av Kibana, der man kan spesifisere nøyaktige tilganger for ulike brukere. Men for autentisering mellom tjenester, som for eksempel kommunikasjon mellom Logstash og Elasticsearch, er API-nøkler langt mer hensiktsmessige. Denne tilnærmingen samsvarer med beste sikkerhetspraksis ved å skille menneskelige brukeres tilgang fra tjenestekontoer og automatisk rotere og tilbakekalle nøkler når det er nødvendig.

I dette kapittelet vil vi gå gjennom hvordan du kan lage og bruke API-nøkler i Kibana, samt hvordan du korrekt kan tilpasse tilgangskontrollen for disse nøklene.

Hvordan opprette og bruke API-nøkler

I kapittel 5 installerte vi en selvstyrt Logstash-instans og konfigurerte en pipeline for å hente Rennes trafikkdata inn i vårt Elastic-deployment. Vi brukte grunnleggende autentisering med administratorkontoen vår for Elasticsearch-utgangen i Logstash-pipelinen. Nå skal vi erstatte den grunnleggende autentiseringen med en API-nøkkel.

Følg disse trinnene:

1. Opprette API-nøkkelen: Start med å opprette en API-nøkkel via Kibanas API. Vi gir denne nøkkelen nødvendige cluster- og indeksprivilegier for å kunne lese og skrive til Rennes-trafikkdataene. I Kibana, gå til Dev Tools og kjør følgende kommando:

   json
   Copy code
   POST /_security/api_key
   
   {
     "name": "rennes_traffic_writer_key",
     "role_descriptors": {
       "rennes_traffic_writer": {
         "cluster": ["monitor", "manage_ilm", "read_ilm"],
         "index": [
           {
             "names": ["metric-rennes_traffic-*"],
             "privileges": ["view_index_metadata", "create_doc"]
           }
         ]
       }
     }
   }
   

2. Reponse etter API-nøkkelopprettelse: Etter at kommandoen er kjørt, vil du få en respons som inneholder både api_key_id og api_key_value. Disse verdiene vil vi bruke for å oppdatere Logstash-konfigurasjonsfilen.

3. Oppdatere Logstash-konfigurasjonen: Åpne Logstash-konfigurasjonsfilen (logstash.conf), og erstatt eksisterende autentisering med API-nøkkelen. Du må legge inn verdiene for CLOUD_ID, api_key_id, og api_key_value i utdata-delen av konfigurasjonen:

   plaintext
   Copy code
   output {
     elasticsearch {
       cloud_id => "CLOUD_ID"
       api_key => "api_key_id:api_key_value"
       data_stream => true
       data_stream_type => "metrics"
       data_stream_dataset => "rennes_traffic"
       data_stream_namespace => "raw"
     }
     stdout { codec => rubydebug }
   }
   

4. Start Logstash-tjenesten på nytt: Etter at du har oppdatert konfigurasjonen, logg inn på den virtuelle maskinen som hoster Logstash. Stopp først Logstash-tjenesten:

   bash
   Copy code
   $ sudo systemctl stop logstash.service
   
   

   Erstatt deretter den gamle logstash.conf-filen med den nye. Start tjenesten på nytt:

   bash
   Copy code
   $ sudo systemctl start logstash.service
   

5. Bekreft at dataene strømmer: Vent i omtrent 10 minutter og sjekk om dataene vises i Kibana. Gå til Analytics -> Discover og velg metrics-rennes_traffic-raw. Du bør nå kunne se de nyeste dataene som er hentet inn.

6. Verifisere API-nøkkelstatus i Kibana: For å sjekke statusen til API-nøkkelen, gå til Stack Management -> API keys i Kibana, finn nøkkelen du opprettet og bekreft at privilegiene er riktig konfigurert.

Hvordan API-nøkler fungerer

Bruken av API-nøkler som autentisering for Logstash består av fire hovedkomponenter:

• API-nøkkelopprettelse: Nøkkelen opprettes via Kibanas Dev Tools-konsoll, og den må ha formatet id:apikey for å kunne brukes med Elasticsearch-utgangspluginnen i Logstash. Dette er grunnen til at du ikke kan opprette API-nøkler direkte i Kibana UI, ettersom de bare støtter kodet API-nøkkelverdi.

• Tildeling av privilegier: Privilegiene definerer hvilke handlinger API-nøkkelens bruker kan utføre. I vårt eksempel inkluderer det å skrive data til Rennes-trafikkstrømmen og overvåke indekslivssyklusene.

• Utløpstid: API-nøkler kan opprettes med eller uten utløpstid, avhengig av behovet for automatisk fornyelse.

• Bruk av API-nøkkel i Logstash: API-nøkkelen konfigureres deretter i logstash.conf-filen i utdata-seksjonen, og erstatter brukerautentisering med grunnleggende legitimasjon.

Andre bruksområder og vurderinger

API-nøkler er ikke bare nyttige for Logstash-tjenesten, men kan også brukes til å filtrere og lese data fra Elasticsearch ved hjelp av både inngangs- og filterpluginner i Logstash. For detaljerte instruksjoner om API-nøkler for Logstash, kan du sjekke Elastic-dokumentasjonen for Elasticsearch input plugin og filter plugin.

En annen viktig fordel ved bruk av API-nøkler er forbedret sporbarhet og revisjonslogg. Fordi API-nøkler kan tildeles spesifikke applikasjoner eller bruksområder, gir dette bedre muligheter for å spore hvilke handlinger som ble utført og hvem som utførte dem. Dette er en stor fordel sammenlignet med bruken av generiske brukerkontoer.

Viktige tillegg

Det er viktig å merke seg at API-nøkler, til tross for deres fleksibilitet og sikkerhet, ikke bør brukes til lange tidsperioder uten rotasjon. Det er avgjørende å ha rutiner på plass for å rotere og tilbakekalle nøklene etter behov, spesielt i et produksjonsmiljø. Sørg også for at nødvendige privilegier til API-nøklene er spesifikke og bare gir tilgang til de nødvendige ressursene, noe som minimerer risikoen for utilsiktet eksponering eller skade.