Preparando-se para implementar as cadeias de ferramentas do DevSecOps em um ambiente protegido por firewall

Em um ambiente empresarial seguro, a equipe do DevOps cria cadeias de ferramentas em um ambiente hospedado privado para garantir que a conformidade, o controle e a automação sejam totalmente funcionais em uma cadeia de ferramentas. A equipe simplifica a entrega de software para manter a propriedade completa da infraestrutura.

Durante a criação e a execução da cadeia de ferramentas em um ambiente hospedado privado, a equipe do DevOps enfrenta desafios de integração e problemas de gerenciamento de segurança por meio das cargas de trabalho do pipeline.

Para superar os desafios. Siga as etapas que descrevem os pré-requisitos, a configuração e as permissões para criar a solução DevSecOps para o Apps Stack em uma conta IBM Cloud® quando o código-fonte do cliente estiver hospedado em um ambiente protegido por firewall.

Planejamento e definição de infraestrutura

Identifique seu ambiente de hospedagem, como data center local, nuvem privada ou nuvem híbrida, onde implantar e como conectar a rede e proteger seu ambiente.

Instalação de um trabalhador privado em sua infraestrutura

Para instalar o trabalhador privado, consulte a documentação sobre a instalação do trabalhador privado do pipeline de entrega.

Protegendo o Ambiente

Você precisa proteger o ambiente usando IAM, gerenciador de segredos, chaves de API ou criptografia. Crie uma chave de API do serviço IBM Cloud® com as permissões corretas para a criação da Arquitetura Implantável (DA). Consulte as permissões descritas em DevSecOps Solutions for Apps Stack.

  • Crie uma chave de API do serviço IBM Cloud® para o trabalhador privado.

  • Crie um token de acesso para conectar o repositório de origem.

Configuração da rede

O firewall deve permitir a conectividade de rede entre o ambiente do cliente e os endpoints do IBM Cloud. Para obter mais informações sobre os endpoints de acesso IBM Cloud, consulte IBM Cloud endpoints.

Cenários de casos de uso e contextos de aplicativos

Configuração do acionamento do Git

Você precisa criar e configurar acionadores de pipeline para que os eventos nos repositórios protegidos por firewall executem os acionadores de pipeline corretos.

A seguir estão os três acionadores:

Acionador do pipeline de CI

  1. Faça login no console IBM Cloud.

  2. Clique no ícone de hambúrguer Menu > Platform Automation > Toolchains.

  3. Clique em sua cadeia de ferramentas de CI > <your CI pipeline>.

  4. Obtenha o pipelineID do URL https://cloud.ibm.com/devops/pipelines/tekton/<CI_PIPELINE_ID>?env_id=ibm:yp:<REGION>

  5. Crie o seguinte arquivo JSON, data_push.json :

    {
    "enabled": true,
    "event_listener": "ci-listener-gitlab",
    "filter": "header['x-gitlab-event'] == 'Push Hook' && body.ref == 'refs/heads/main'",
    "max_concurrent_runs": 1,
    "name": "Git Trigger",
    "secret": {
        "key_name": "X-Gitlab-Token",
        "source": "header",
        "type": "token_matches",
        "value": "<WEBHOOK_SECRET>"
    },
    "type": "generic",
    "worker": {
        "id": "inherit"
    }
}

  6. Obter as credenciais da conta IBM

    • Faça login na CLI do IBM Cloud com ibmcloud login.
    • Obtenha um token de portador do IAM como IAM_TOKEN=$(ibmcloud iam oauth-tokens)

  7. Configurar variáveis de ambiente

    IAM_TOKEN=${IAM_TOKEN:33}
CI_PIPELINE_ID=36127d0b-1858-404b-b3ee-7a68aefec994
REGION=us-south

  8. Execute o comando cURL a seguir.

    `curl -X POST --location --header "Authorization: Bearer ${IAM_TOKEN}" --header "Accept: application/json" --header "Content-Type: application/json" --data @data_push.json "https://api.${REGION}.devops.cloud.ibm.com/pipeline/v2/tekton_pipelines/${CI_PIPELINE_ID}/triggers"`

    A resposta JSON do comando CURL tem a aparência mostrada no bloco de código.

    {
  "type": "generic",
  "name": "Git Trigger",
  "event_listener": "ci-listener-gitlab",
  "id": "ef110ae8-2395-4928-9dba-f80b49cab276",
  "filter": "header['x-gitlab-event'] == 'Push Hook' && body.ref == 'refs/heads/main'",
  "secret": {
    "type": "token_matches",
    "value": "hash:SHA3-512:7a4f5b0701a921c9054eb41d97258979389922592801d21d213bdb5aa99cb8aec71368153fe0a084e7c9e5be119976a8279cfa0e794de90036fe138a57e4fd31",
    "source": "header",
    "key_name": "X-Gitlab-Token"
  },
  "properties": [],
  "webhook_url": "https://devops-api.us-south.devops.cloud.ibm.com/v1/tekton-webhook/f6e201e0-ba61-4e88-9a1b-6fc81febb952/run/ef110ae8-2395-4928-9dba-f80b49cab276",
  "max_concurrent_runs": 1,
  "enabled": true,
  "href": "https://api.us-south.devops.cloud.ibm.com/pipeline/v2/tekton_pipelines/f6e201e0-ba61-4e88-9a1b-6fc81febb952/triggers/ef110ae8-2395-4928-9dba-f80b49cab276"
}

Copie o campo href da resposta e adicione a palavra-chave private no ponto de extremidade, conforme mostrado no exemplo - https://api.private.us-south.devops.cloud.ibm.com/pipeline/v2/tekton_pipelines/f6e201e0-ba61-4e88-9a1b-6fc81febb952/triggers/ef110ae8-2395-4928-9dba-f80b49cab276

Criação de webhook de repositório de origem para pipeline de CI

Você precisa criar um webhook de repositório para invocar o acionador criado.

  1. Navegue até a página de webhooks de seu repositório de código-fonte protegido por firewall, por exemplo https://my-private-gitlab/test-admin/code-engine-compliance-app/-/hooks
  2. Clique em Add new webhook.
  3. Preencha o campo URL usando o campo href modificado do acionador criado anteriormente. Por exemplo,https://api.private.us-south.devops.cloud.ibm.com/pipeline/v2/tekton_pipelines/f6e201e0-ba61-4e88-9a1b-6fc81febb952/triggers/ef110ae8-2395-4928-9dba-f80b49cab276
  4. Escolha um nome significativo. Por exemplo, CI Pipeline webhook.
  5. Preencha o campo Segredo token com o valor <WEBHOOK_SECRET> usado ao criar o acionador do pipeline
  6. Selecione Eventos push > Todos os ramos como opções de acionamento.
  7. Clique em Add webhook para manter suas alterações.

O valor do campo URL pode ser recuperado do valor do campo Webhook URL do acionador por meio da interface do usuário do pipeline após a criação do pipeline de CI. O segredo usado pelo webhook e pelo par de acionadores pode ser modificado.

Acionador do pipeline de RP

  1. Faça login no console IBM Cloud.

  2. Clique no ícone de hambúrguer Menu > Platform Automation > Toolchains.

  3. Clique em sua cadeia de ferramentas de relações públicas > <your CR pipeline>.

  4. Obtenha o pipelineID do URL. Por exemplo, https://cloud.ibm.com/devops/pipelines/tekton/<PR_PIPELINE_ID>?env_id=ibm:yp:<REGION>.

  5. Crie o seguinte arquivo JSON, data_merge.json.

    {
    "enabled": true,
    "event_listener": "pr-listener-gitlab",
    "filter": "header['x-gitlab-event'] == 'Merge Request Hook' && (body.object_attributes.action == 'open' || body.object_attributes.action == 'update' || body.object_attributes.action == 'reopen') && body.object_attributes.target_branch == 'main'",
    "max_concurrent_runs": 1,
    "name": "PR Git Trigger",
    "secret": {
        "key_name": "X-Gitlab-Token",
        "source": "header",
        "type": "token_matches",
        "value": "<WEBHOOK_SECRET>"
    },
    "type": "generic",
    "worker": {
        "id": "inherit"
    }
}

  6. Obter as credenciais da conta IBM

    • Faça login na CLI do IBM Cloud com ibmcloud login.
    • Obtenha um token de portador do IAM como IAM_TOKEN=$(ibmcloud iam oauth-tokens)

  7. Configurar variáveis de ambiente

    IAM_TOKEN=${IAM_TOKEN:33}
CI_PIPELINE_ID=36127d0b-1858-404b-b3ee-7a68aefec994
REGION=us-south

  8. Execute o comando cURL a seguir.

    `curl -X POST --location --header "Authorization: Bearer ${IAM_TOKEN}" --header "Accept: application/json" --header "Content-Type: application/json" --data @data_merge.json "https://api.${REGION}.devops.cloud.ibm.com/pipeline/v2/tekton_pipelines/${PR_PIPELINE_ID}/triggers"`

    A resposta JSON do comando CURL tem a aparência mostrada no bloco de código.

    {
  "type": "generic",
  "name": "PR Git Trigger",
  "event_listener": "ci-listener-gitlab",
  "id": "ef110ae8-2395-4928-9dba-f80b49cab276",
  "filter": "header['x-gitlab-event'] == 'Merge Request Hook' && (body.object_attributes.action == 'open' || body.object_attributes.action == 'update' || body.object_attributes.action == 'reopen') && body.object_attributes.target_branch == 'main'",
  "secret": {
    "type": "token_matches",
    "value": "hash:SHA3-512:7a4f5b0701a921c9054eb41d97258979389922592801d21d213bdb5aa99cb8aec71368153fe0a084e7c9e5be119976a8279cfa0e794de90036fe138a57e4fd31",
    "source": "header",
    "key_name": "X-Gitlab-Token"
  },
  "properties": [],
  "webhook_url": "https://devops-api.us-south.devops.cloud.ibm.com/v1/tekton-webhook/f6e201e0-ba61-4e88-9a1b-6fc81febb952/run/ef110ae8-2395-4928-9dba-f80b49cab276",
  "max_concurrent_runs": 1,
  "enabled": true,
  "href": "https://api.us-south.devops.cloud.ibm.com/pipeline/v2/tekton_pipelines/f6e201e0-ba61-4e88-9a1b-6fc81febb952/triggers/ef110ae8-2395-4928-9dba-f80b49cab276"
}

Copie o campo href da resposta e adicione a palavra-chave private no endpoint. Por exemplo, https://api.private.us-south.devops.cloud.ibm.com/pipeline/v2/tekton_pipelines/f6e201e0-ba61-4e88-9a1b-6fc81febb952/triggers/ef110ae8-2395-4928-9dba-f80b49cab276

Criação de webhook do repositório de origem para o pipeline de PR

Você precisa criar um webhook de repositório para invocar o acionador criado.

  1. Navegue até a página de webhooks de seu repositório de código-fonte protegido por firewall. Por exemplo, https://my-private-gitlab/test-admin/code-engine-compliance-app/-/hooks.
  2. Clique em Add new webhook.
  3. Preencha o campo URL usando o campo href modificado do acionador criado anteriormente. Por exemplo, https://api.private.us-south.devops.cloud.ibm.com/pipeline/v2/tekton_pipelines/f6e201e0-ba61-4e88-9a1b-6fc81febb952/triggers/ef110ae8-2395-4928-9dba-f80b49cab276.
  4. Escolha um nome significativo. Por exemplo, PR Pipeline webhook.
  5. Preencha o campo Segredo token com o valor <WEBHOOK_SECRET> usado ao criar o acionador do pipeline
  6. Selecione Eventos push > Todos os ramos como opções de acionamento.
  7. Clique em Add webhook para manter suas alterações.

O valor do campo URL pode ser recuperado do valor do campo Webhook URL do acionador na interface do usuário do pipeline a qualquer momento após a criação. O segredo que é usado pelo webhook e pelo par de acionadores pode ser modificado.

Acionamento do pipeline de CD

  1. Faça login no console IBM Cloud.

  2. Clique no ícone de hambúrguer Menu > Platform Automation > Toolchains.

  3. Clique em sua cadeia de ferramentas de CD > <your CD pipeline>.

  4. Obtenha o pipelineID do URL. Por exemplo, https://cloud.ibm.com/devops/pipelines/tekton/<CD_PIPELINE_ID>?env_id=ibm:yp:<REGION>.

  5. Crie o seguinte arquivo JSON, data_cd_merge.json :

    
    "enabled": true,
    "event_listener": "promotion-validation-listener-gitlab",
    "filter": "header['x-gitlab-event'] == 'Merge Request Hook' && (body.object_attributes.action == 'open' || body.object_attributes.action == 'reopen') && body.object_attributes.target_branch == 'prod'",
    "max_concurrent_runs": 1,
    "name": "Git Promotion Validation Trigger",
    "secret": {
        "key_name": "X-Gitlab-Token",
        "source": "header",
        "type": "token_matches",
        "value": "<WEBHOOK_SECRET>"
    },
    "type": "generic",
    "worker": {
        "id": "inherit"
    }

  6. Obter as credenciais da conta IBM

    • Faça login na CLI do IBM Cloud com ibmcloud login.
    • Obtenha um token de portador do IAM como IAM_TOKEN=$(ibmcloud iam oauth-tokens)

  7. Configurar variáveis de ambiente

    IAM_TOKEN=${IAM_TOKEN:33}
CI_PIPELINE_ID=36127d0b-1858-404b-b3ee-7a68aefec994
REGION=us-south

  8. Execute o comando cURL a seguir.

    `curl -X POST --location --header "Authorization: Bearer ${IAM_TOKEN}" --header "Accept: application/json" --header "Content-Type: application/json" --data @data_cd_merge.json "https://api.${REGION}.devops.cloud.ibm.com/pipeline/v2/tekton_pipelines/${CD_PIPELINE_ID}/triggers"`

    A resposta JSON do comando CURL tem a aparência mostrada no bloco de código.

    {
  "type": "generic",
  "name": "Git Promotion Validation Trigger",
  "event_listener": "ci-listener-gitlab",
  "id": "ef110ae8-2395-4928-9dba-f80b49cab276",
  "filter": "header['x-gitlab-event'] == 'Merge Request Hook' && (body.object_attributes.action == 'open' || body.object_attributes.action == 'reopen') && body.object_attributes.target_branch == 'prod'",
  "secret": {
    "type": "token_matches",
    "value": "hash:SHA3-512:7a4f5b0701a921c9054eb41d97258979389922592801d21d213bdb5aa99cb8aec71368153fe0a084e7c9e5be119976a8279cfa0e794de90036fe138a57e4fd31",
    "source": "header",
    "key_name": "X-Gitlab-Token"
  },
  "properties": [],
  "webhook_url": "https://devops-api.us-south.devops.cloud.ibm.com/v1/tekton-webhook/f6e201e0-ba61-4e88-9a1b-6fc81febb952/run/ef110ae8-2395-4928-9dba-f80b49cab276",
  "max_concurrent_runs": 1,
  "enabled": true,
  "href": "https://api.us-south.devops.cloud.ibm.com/pipeline/v2/tekton_pipelines/f6e201e0-ba61-4e88-9a1b-6fc81febb952/triggers/ef110ae8-2395-4928-9dba-f80b49cab276"
}

Copie o campo href da resposta e adicione a palavra-chave private. Por exemplo, https://api.private.us-south.devops.cloud.ibm.com/pipeline/v2/tekton_pipelines/f6e201e0-ba61-4e88-9a1b-6fc81febb952/triggers/ef110ae8-2395-4928-9dba-f80b49cab276

Criação de webhook de repositório de inventário para pipeline de CD

Você precisa criar um webhook de repositório para invocar o acionador criado.

  1. Navegue até a página de webhooks de seu repositório de código-fonte protegido por firewall. Por exemplo, https://my-private-gitlab/test-admin/compliance-inventory2/-/hooks.
  2. Clique em Add new webhook.
  3. Preencha o campo URL usando o campo href modificado do acionador criado anteriormente. Por exemplo, https://api.private.us-south.devops.cloud.ibm.com/pipeline/v2/tekton_pipelines/f6e201e0-ba61-4e88-9a1b-6fc81febb952/triggers/ef110ae8-2395-4928-9dba-f80b49cab276.
  4. Escolha um nome significativo. Por exemplo, Promotion Validation webhook.
  5. Preencha o campo Segredo token com o valor <WEBHOOK_SECRET> usado ao criar o acionador do pipeline
  6. Selecione Eventos push > Todas as ramificações como opções de acionamento
  7. Clique em Add webhook para manter suas alterações.

O valor do campo URL pode ser recuperado do valor do campo Webhook URL do acionador por meio da interface do usuário do pipeline após a criação do pipeline de CD. O segredo que é usado pelo webhook e pelo par de acionadores pode ser modificado.

Cenário 1: Pré-requisitos de vedação totalmente a ar

Nesse cenário, você hospedou um repositório de aplicativos em uma instância privada do GitLab e todos os repositórios de conformidade do DevSecOps necessários para operar as cadeias de ferramentas. Para essas etapas, a instância GitLab com espaço aéreo é chamada de https://my-private-gitlab/ e o usuário ou proprietário Git de test-user

Os repositórios necessários podem ser baixados dos seguintes URLs. Us-south é o exemplo dado, mas pode ser substituído por qualquer um dos seguintes: us-south, eu-gb, au-syd, eu-de, jp-tok, jp-osa, eu-es, ou ca-tor.

Os repositórios necessários para uma configuração totalmente com espaço aéreo
URL Descrição
https://us-south.git.cloud.ibm.com/open-toolchain/code-engine-compliance-app O repositório de aplicativos de amostra Code Engine.
https://us-south.git.cloud.ibm.com/open-toolchain/hello-compliance-app O repositório de aplicativos de amostra Kubernetes.
https://us-south.git.cloud.ibm.com/open-toolchain/compliance-evidence-locker O repositório de evidências de conformidade.
https://us-south.git.cloud.ibm.com/open-toolchain/compliance-incident-issues O repositório de questões de conformidade.
https://us-south.git.cloud.ibm.com/open-toolchain/compliance-inventory O repositório de inventário de conformidade.
https://us-south.git.cloud.ibm.com/open-toolchain/compliance-change-management O repositório de gerenciamento de alterações de conformidade.
https://us-south.git.cloud.ibm.com/open-toolchain/hello-compliance-deployment O repositório de amostra que contém scripts de implantação. Não é necessário ao usar a amostra Code Engine que contém todos os scripts necessários.
https://us-south.git.cloud.ibm.com/open-toolchain/compliance-pipelines O repositório de conformidade que contém todas as definições de pipeline.

Os repositórios ou o conteúdo dos repositórios precisam ser espelhados no ambiente com espaço aéreo. Por exemplo, o site URL para o aplicativo de código de amostra é https://my-private-gitlab/test-user/code-engine-compliance-app

Neste exemplo, os repositórios são configurados da seguinte forma para o aplicativo Code Engine.

Os repositórios, depois de serem instalados no ar, abriram uma lacuna privada GitLab
URL
https://my-private-gitlab/test-admin/code-engine-compliance-app
https://my-private-gitlab/test-admin/compliance-evidence
https://my-private-gitlab/test-admin/compliance-issues
https://my-private-gitlab/test-admin/compliance-inventory
https://my-private-gitlab/test-admin/compliance-change-management
https://my-private-gitlab/test-admin/compliance-pipelines

Um token de acesso pessoal Git é necessário para configurar as integrações da ferramenta de repositório que são mantidas como parte das cadeias de ferramentas DevSecOps e a chave da API de serviço para a integração da ferramenta de pipeline.

Cenário 1: configuração totalmente vedada com ar

Agora, você está pronto para configurar as variáveis de segurança, obrigatórias e opcionais para uma implantação de air gapped usando o aplicativo de amostra Code Engine.

Os URLs do repositório são específicos para este exemplo e os URLs usados devem refletir seu ambiente.

  1. Na seção Configurar, selecione o método de autenticação. Você pode usar um segredo existente em Secrets Manager, adicionar sua chave de API diretamente ou definir um Trusted Profile. Para obter mais informações, consulte Uso de uma chave ou segredo de API para autorizar um projeto a implantar uma arquitetura.
  2. Na guia Required (Obrigatório ), insira valores para os campos obrigatórios.
  3. Há três campos de região:
    • O primeiro declara a região na qual todos os serviços são implantados.
    • O segundo é para a região na qual o serviço de Segurança e Conformidade está implantado.
    • A terceira é para Event Notifications. Por padrão, eles são definidos como us-south. Se você alterar o padrão, certifique-se de que as três regiões estejam todas configuradas da mesma forma.
  4. No conjunto app_repo_existing_url https://my-private-gitlab/test-admin/code-engine-compliance-app.
  5. Na guia Optional (Opcional ), localize as seguintes variáveis e defina os valores conforme indicado.
    • create_git_token- alternar para true.
    • repo_git_token_secret_name- defina um nome para seu token. Esse é o nome que aparece para o segredo do token Git em Secrets Manager.
    • repo_git_token_secret_value- defina o token de acesso pessoal Git para acessar os repositórios da equipe.
    • repo_group- define o nome do grupo de repositórios ou o nome do proprietário.
    • repo_apply_settings_to_compliance_repos - true
    • repo_git_provider - gitlab
    • repo_title- definir um nome de título de repositório. Por exemplo, development server.
    • repo_root_url- definido de acordo com sua própria instância privada do GitLab. Por exemplo, https://my-private-gitlab
    • repo_blind_connection - true
    • repo_git_id - gitlabcustom
    • evidence_repo_existing_url - https://my-private-gitlab/test-admin/compliance-evidence
    • issues_repo_existing_url - https://my-private-gitlab/test-admin/compliance-issues
    • inventory_repo_existing_url - https://my-private-gitlab/test-admin/compliance-inventory
    • change_management_existing_url - https://my-private-gitlab/test-admin/compliance-change-management
    • compliance_pipeline_existing_repo_url - https://my-private-gitlab/test-admin/compliance-pipelines
    • app_repo_branch- Certifique-se de que o nome da ramificação corresponda à ramificação de um exemplo. Para a amostra Code Engine, defina como main.
    • create_triggers - true
    • create_git_triggers - false
    • compliance_pipeline_repo_use_group_settings - true
    • create_privateworker_secret - true
    • enable_privateworker - true
    • privateworker_credentials_secret_name- defina um nome como você gostaria que o segredo do trabalhador privado aparecesse em Secrets Manager.
    • privateworker_secret_value- Fornecer chave de API de serviço de trabalhador privado.
  6. Clique no botão Salvar.

Cenário 1: (Opcional) Configuração totalmente Air Gapped usando um grupo de recursos pré-existente

  1. Navegue até o nível de projetos e localize a pilha atual. Expanda a pilha e localize o membro Compliance Manager. Clique no menu Options ou Kebab.
  2. Selecione Editar > guia Opcional, localize as seguintes variáveis e defina os valores conforme indicado.
    • resource_group_name- Forneça o nome de um grupo de recursos existente no qual a pilha provisiona os recursos.
    • use_existing_resource_group - true
  3. Clique no botão Salvar. Não valide neste momento.
  4. Navegue de volta ao nível de Projetos e localize a pilha atual. Expanda a pilha e encontre o membro Compliance Manager. Clique no menu Options ou Kebab.
  5. Selecione a guia Optional (Opcional ) para visualizar a configuração do site Compliance Manager.
  6. Edite a variável resource_groups_scope e defina o nome do grupo de recursos existente entre aspas dentro dos colchetes. Por exemplo, ["my-resource-group"].
  7. Clique no botão Salvar.

Cenário 1: Execução da pilha totalmente vedada com ar

  1. Navegue até o nível superior do projeto.
  2. Clique na opção Gerenciar > Configurações no nível do projeto.
  3. Defina Auto-deploy como ativado para implantar todas as configurações da pilha sem exigir que cada implantação de configuração seja iniciada manualmente.
  4. Clique na guia Configurações.
  5. Clique nas opções ou no menu Kebab da configuração da pilha para expandir.
  6. Clique em **Validate and deploy para iniciar a implantação após a conclusão da validação.

Cenário 2: totalmente hermético, exceto pelos dutos de conformidade

Nesse cenário, você pode vincular-se a um repositório de pipelines de conformidade existente e manter-se sempre atualizado com as definições de pipeline mais recentes.

Caso contrário, o usuário deverá verificar periodicamente o estado do repositório em https://us-south.git.cloud.ibm.com/open-toolchain/compliance-pipelines e copiar manualmente as alterações para o repositório privado GitLab.

  1. Siga as etapas indicadas no Cenário 1: configuração com vedação total de ar.
  2. Quando você chegar à etapa de definição de compliance_pipeline_existing_repo_url, deixe o valor vazio.
  3. Encontre a entrada compliance_pipeline_repo_use_group_settings e defina-a como false.
  4. Continue as etapas restantes da configuração do Cenário 1: totalmente vedada com ar.

Cenário 3: Configuração híbrida com folga de ar

Nesse cenário, somente os repositórios que contêm o código do aplicativo e os scripts são armazenados na instância privada do GitLab. Os demais repositórios de conformidade usam a solução hospedada padrão IBM Git.

  1. Siga as etapas indicadas no Cenário 1: configuração com vedação total de ar.
  2. Quando você chegar à etapa de definição de compliance_pipeline_existing_repo_url, deixe o valor vazio.
  3. Localize a entrada compliance_pipeline_repo_use_group_settings e defina-a como false, e deixe as seguintes entradas de variáveis vazias.
    • evidence_repo_existing_url
    • issues_repo_existing_url
    • inventory_repo_existing_url
    • change_management_existing_url
  4. Encontre a entrada repo_apply_settings_to_compliance_repos e defina-a como false.
  5. Continue as etapas restantes da configuração do Cenário 1: totalmente vedada com ar.
Configuração do aplicativo de conformidade Code Engine cenário 1
Nome Valor
app_repo_branch main
app_repo_existing_url https://my-private-gitlab/test-admin/code-engine-app
use_app_repo_for_cd_deploy Não
cd_deployment_repo_existing_url https://my-private-gitlab/test-admin/hello-compliance-deployment
create_git_token verdadeiro
create_triggers verdadeiro
create_git_triggers Não
compliance_pipeline_repo_use_group_settings verdadeiro
add_pipeline_definitions verdadeiro
create_privateworker_secret verdadeiro
enable_privateworker verdadeiro
privateworker_credentials_secret_name chave privada do trabalhador
privateworker_secret_value <Service-API-Key>
repo_apply_settings_to_compliance_repos Não
repo_title My Git Enterprise Server
repo_root_url https://my-private-gitlab/
repo_blind_connection verdadeiro
repo_git_id gitlabcustom
repo_group test-user
repo_git_provider gitlab
repo_git_token_secret_name gitlab-token
repo_git_token_secret_value <Access-Token>

Veja a seguir as dicas importantes para configurar o parâmetro no aplicativo

  • Se estiver usando um repositório de aplicativos que contenha os scripts de implementação, como o Code Engine, você poderá definir use_app_repo_for_cd_deploy como true e deixar cd_deployment_repo_existing_url sem definição.

  • Se você já tiver uma instância de Secrets Manager de que precisa, use existing_secrets_manager_crn.