Translated ['.github/pull_request_template.md', 'src/pentesting-cloud/az

src/pentesting-cloud/openshift-pentesting/openshift-jenkins/README.md

@@ -1,43 +1,39 @@
 # OpenShift - Jenkins
 
-**The original author of this page is** [**Fares**](https://www.linkedin.com/in/fares-siala/)
+**このページの元の著者は** [**Fares**](https://www.linkedin.com/in/fares-siala/)
 
-This page gives some pointers onto how you can attack a Jenkins instance running in an Openshift (or Kubernetes) cluster
+このページでは、OpenShift（またはKubernetes）クラスターで実行されているJenkinsインスタンスを攻撃する方法についてのいくつかのポイントを示します。
 
-## Disclaimer
+## 免責事項
 
-A Jenkins instance can be deployed in both Openshift or Kubernetes cluster. Depending in your context, you may need to adapt any shown payload, yaml or technique. For more information about attacking Jenkins you can have a look at [this page](../../../pentesting-ci-cd/jenkins-security/)
+Jenkinsインスタンスは、OpenShiftまたはKubernetesクラスターの両方にデプロイできます。あなたのコンテキストに応じて、表示されているペイロード、yaml、または技術を適応させる必要があるかもしれません。Jenkinsを攻撃することに関する詳細情報は、[このページ](../../../pentesting-ci-cd/jenkins-security/)を参照してください。
 
-## Prerequisites
+## 前提条件
 
-1a. User access in a Jenkins instance OR 1b. User access with write permission to an SCM repository where an automated build is triggered after a push/merge
+1a. Jenkinsインスタンスへのユーザーアクセス または 1b. プッシュ/マージ後に自動ビルドがトリガーされるSCMリポジトリへの書き込み権限を持つユーザーアクセス
 
-## How it works
+## 仕組み
 
-Fundamentally, almost everything behind the scenes works the same as a regular Jenkins instance running in a VM. The main difference is the overall architecture and how builds are managed inside an openshift (or kubernetes) cluster.
+基本的に、裏側でのほとんどすべては、VMで実行されている通常のJenkinsインスタンスと同じように機能します。主な違いは、全体のアーキテクチャと、OpenShift（またはKubernetes）クラスター内でのビルドの管理方法です。
 
-### Builds
+### ビルド
 
-When a build is triggered, it is first managed/orchestrated by the Jenkins master node then delegated to an agent/slave/worker. In this context, the master node is just a regular pod running in a namespace (which might be different that the one where workers run). The same applies for the workers/slaves, however they destroyed once the build finished whereas the master always stays up. Your build is usually run inside a pod, using a default pod template defined by the Jenkins admins.
+ビルドがトリガーされると、最初にJenkinsマスターノードによって管理/オーケストレーションされ、その後エージェント/スレーブ/ワーカーに委任されます。このコンテキストでは、マスターノードは単に名前空間内で実行されている通常のポッドです（ワーカーが実行されているものとは異なる場合があります）。ワーカー/スレーブにも同様のことが当てはまりますが、ビルドが終了すると破棄されるのに対し、マスターは常に稼働し続けます。あなたのビルドは通常、Jenkins管理者によって定義されたデフォルトのポッドテンプレートを使用してポッド内で実行されます。
 
-### Triggering a build
+### ビルドのトリガー
 
-You have multiples main ways to trigger a build such as:
+ビルドをトリガーする主な方法はいくつかあります：
 
-1. You have UI access to Jenkins
+1. JenkinsへのUIアクセスがある
 
-A very easy and convenient way is to use the Replay functionality of an existing build. It allows you to replay a previously executed build while allowing you to update the groovy script. This requires privileges on a Jenkins folder and a predefined pipeline. If you need to be stealthy, you can delete your triggered builds if you have enough permission.
+非常に簡単で便利な方法は、既存のビルドのリプレイ機能を使用することです。これにより、以前に実行されたビルドをリプレイしながら、groovyスクリプトを更新できます。これにはJenkinsフォルダーに対する権限と、事前定義されたパイプラインが必要です。ステルス性が必要な場合は、十分な権限があればトリガーしたビルドを削除できます。
 
-2. You have write access to the SCM and automated builds are configured via webhook
+2. SCMへの書き込みアクセスがあり、自動ビルドがWebhookを介して構成されている
 
-You can just edit a build script (such as Jenkinsfile), commit and push (eventually create a PR if builds are only triggered on PR merges). Keep in mind that this path is very noisy and need elevated privileges to clean your tracks.
+ビルドスクリプト（Jenkinsfileなど）を編集し、コミットしてプッシュするだけです（ビルドがPRマージ時のみトリガーされる場合は、最終的にPRを作成します）。この方法は非常に騒がしいことを覚えておいてください。足跡を消すには、昇格した権限が必要です。
 
-## Jenkins Build Pod YAML override
+## JenkinsビルドポッドYAMLオーバーライド
 
 {{#ref}}
 openshift-jenkins-build-overrides.md
 {{#endref}}
-
-
-
-