新しい投稿

検索

お知らせ
· 2024年10月13日

加入 InterSystems 步行挑战!

开发者社区的成员,大家好!

我们都喜欢编码,但我们应该时不时地放下代码去锻炼身体! InterSystems 步行挑战将帮助您恢复精力、增强体质。 历史悠久的 Salt Road 在几个世纪以前连接起欧洲,沿着这条传奇的贸易路线,踏上从吕贝克到吕讷堡的虚拟赛道。

赢取跑步机、智能手表和奖牌等精美礼品。

👟🚶🧑‍🦼系紧鞋带,放下工作,更好地编码! 🔋💻💪

📅日期:9 月 23 日 - 10 月 20 日(可能有变动)

想加入吗? 详细信息如下。

ディスカッション (0)0
続けるにはログインするか新規登録を行ってください
記事
· 2024年10月13日 10m read

IRIS開発における生成AIの活用について

はじめに

生成AIを活用したアプリケーション開発は、Python、JavaScriptなどのメジャー言語による体験記事がよく見られます。一方、IRISのObjectScriptの開発に言及された記事は比較的少ないのが現状です。そこで、本記事では生成AIがObjectScriptの開発にどこまで活用できるのかを検証しました。

特にDevOpsのプロセスにおいて、生成AIは様々なシーンでの活用が期待できます。今回は開発工程に注目し、以下の観点から生成AIの有効性を調査しました。

  • 開発
    • コードの自動生成
    • 環境構築のアシスタント(テーブルの作成)
  • 検証
    • テストデータ生成のサポート

環境

本記事の検証は以下の環境で行いました。

開発環境

ディスカッション (0)1
続けるにはログインするか新規登録を行ってください
記事
· 2024年10月13日 2m read

第四十六章 创建和添加 SAML 令牌 - SubjectConfirmation 使用方法 Holder-of-key

第四十六章 创建和添加 SAML 令牌 - 使用方法 Holder-of-key

添加<Subject>元素

要将 <Subject> 元素添加到 %SAML.Assertion 实例,执行以下操作:
1. 创建 %SAML.Subject 的新实例。
2. 根据需要设置主题的属性。
3. 将断言对象的 Subject 属性设置为等于此实例。

添加 <SubjectConfirmation> 元素

要将 <SubjectConfirmation> 元素添加到的 %SAML.Assertion 实例,请使用以下某个小节中的步骤。

ディスカッション (0)1
続けるにはログインするか新規登録を行ってください
お知らせ
· 2024年10月13日

[Video] Fine-Tuning - second step of GenAI model training

Hi Community!

We're happy to share the next video in the series dedicated to Gen AI on our InterSystems Developers YouTube:

⏯ Fine-Tuning - second step of GenAI model training

Learn about the second step of training a GenAI model, fine-tuning: why it's done, on what data and who's doing it. This step allows you to tailor a pre-trained model to specific tasks or datasets, optimizing its performance for your unique use case. These techniques work together to enhance an AI’s ability to grasp your own context and respond based on your data.

🗣  Presenter@Don Woodlock, Vice President, Healthcare Solutions Development, InterSystems

Enjoy watching, and look forward to more videos! 👍

ディスカッション (0)1
続けるにはログインするか新規登録を行ってください
記事
· 2024年10月12日 9m read

eBPF: Segurança Tetragon para cargas de trabalho IRIS

Runtime Enforcement

 

Até agora, na jornada do eBPF aplicada às cargas de trabalho InterSystems, temos sido praticamente somente leitura quando se trata de chamadas de sistema, execução binária e monitoramento de arquivos.

Mas, assim como as políticas de segurança de rede que estavam em jogo com o último post que impõem conectividade, e se pudermos impor chamadas de sistema, acesso a arquivos e processos da mesma maneira em todo um cluster?

Apresentando Tetragon, uma ferramenta flexível de observabilidade e imposição de segurança sensível ao Kubernetes que aplica política e filtragem diretamente com eBPF, permitindo uma redução de sobrecarga de observação, rastreamento de qualquer processo e imposição em tempo real de políticas.

Imposição quando seu aplicativo não pode fornecê-la.

Onde ele Roda

Observabilidade e Imposição em Todo o Cluster

De pé e rodando

Os passos obrigatórios parra levantar e rodar se você optar por isso, realizados no estilo de um Isovalent Lab.

kubernetes" Icon - Download for free – IconduckCluster

Cluster Kind, 3 nós de trabalho, sem um CNI padrão.

 
kind.sh

Cilium

Instale Cilium, se não for outra coisa, um CNI.

 
cilium.sh



Runtime EnforcementTetragon

Aqui instalamos a estrela do nosso show, Tetragon,  como um conjunto daemon.

 
tetragon.sh

 

Intersystems logo Geometric Uppercase Display Letter i logo, Custom shape Negative Space Flat Two Colors, Blue + Turquoise. Cargas de trabalho IRIS

Pod IRIS rápido, não privilegiado, mas facilmente modificado para ser. Este é o pod que executaremos coisas para explicar algo do comportamento da política de rastreamento.

 
iris.sh

 


Políticas de rastreamento

Políticas de Rastreamento são recursos personalizados que facilitam a configuração de filtros em tempo real para eventos do kernel. Uma Política de Rastreamento combina e filtra chamadas de sistema para observabilidade e também aciona uma ação sobre essas correspondências.

Logo de cara, porém, process_exec e process_exit sem precisar carregar nenhuma política de rastreamento.

Em um terminal, execute seu ZF, no outro, examine os eventos Tetragon:

kubectl exec -ti -n kube-system tetragon-sw9k4 -c tetragon -- tetra getevents -o compact --pods iris-nopriv 

Se dermos uma olhada na execução do processo em Tetragon para a seguinte chamada que imprime o diretório de trabalho atual.


Isso pode ser óbvio para você, mas executar ZF com o argumento "/SHELL" invoca o bash e, em seguida, chama o comando, enquanto quando ele é omitido, ele chama diretamente o binário. Agora usamos a saída compacta acima, mas se você observar os eventos no formato json, pode ver como eles são chamados de forma diferente, com a opção /shell tendo um processo pai.
 

ie:

            "cwd": "/usr/irissys/bin",
            "binary": "/usr/irissys/bin/irisdb",
            "arguments": "-w /home/irisowner -s /usr/irissys/mgr",
            "flags": "execve",

 

 
direct.json

 

 

 
shell.json
 

 

Os eventos JSON são enviados para o log do Tetragon e podem ser enviados para um sistema SIEM ou observabilidade para insights acionáveis

SecurityImposição em Tempo de Execução

Isso pode ser um pouco falto de imaginação para um caso de uso, mas e se quiséssemos proibir qualquer pessoa de chamar e ler o arquivo de licença?

Para isso, precisamos aplicar uma Política de Rastreamento que impõe um matchAction. Essas políticas são um pouco envolvidas, mas esta é a maneira longa de dizer "Ei, se você executar cat /usr/irissys/mgr/iris.key, vou matá-lo (SIGKILL você).

kubectl apply -f - <<EOF
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "iris-read-file-sigkill"
spec:
  kprobes:
  - call: "fd_install"
    syscall: false
    return: false
    args:
    - index: 0
      type: int
    - index: 1
      type: "file"
    selectors:
    - matchPIDs:
      - operator: NotIn
        followForks: true
        isNamespacePID: true
        values:
        - 1
      matchArgs:
      - index: 1
        operator: "Prefix"
        values:
        - "/usr/irissys/secrets/"
        - "/usr/irissys/mgr/iris.key"
        #- "/tmp/" # wrecks havoc
      matchActions:
      - action: FollowFD
        argFd: 0
        argName: 1
  - call: "__x64_sys_close"
    syscall: true
    args:
    - index: 0
      type: "int"
    selectors:
    - matchActions:
      - action: UnfollowFD
        argFd: 0
        argName: 0
  - call: "__x64_sys_read"
    syscall: true
    args:
    - index: 0
      type: "fd"
    - index: 1
      type: "char_buf"
      returnCopy: true
    - index: 2
      type: "size_t"
    selectors:
    - matchActions:
      - action: Sigkill

EOF

Uma vez implantado, você deve vê-lo carregado como um recurso TracingPolicy:

Vamos vê-lo impor a política:

O -1 nos conta que algo está errado, e o comando não teve sucesso.

Mas desconhecido pelo colega brogrammer, nós o bloqueamos administrativamente e enviamos um SIGKILL para o processo!

Essa será uma longa chamada para o WRC para o usuário final desavisado (ou especialista do WRC).

Experimentos

Eu encontrei alguns que eram interessantes nos centenas que eu roubei, apliquei e brinquei, notável foi um que deu as chamadas de sistema por binário. Se você realmente quisesse ser nerd, você poderia literalmente bloquear por syscall.

Outro que foi fascinante foi a Política de Rastreamento de acesso a arquivos, que mostrava todos os processos acessando todos os arquivos.

Essas e outros políticas podem ser encontrados no repositório de examplos @ tetragon:

  • Chamadas de sistema
  • Atributos de processo
  • Argumentos de linha de comando
  • Atividade de rede
  • Operações do sistema de arquivos
ディスカッション (0)1
続けるにはログインするか新規登録を行ってください