When securing the application delivery process to a Kubernetes cluster end to end, many different components need to be secured:
+ CI/CD pipeline
+ Container registry
+ Git repository
+ Kubernetes cluster
+ Cloud provider or data center
+ The application itself
+ GitOps operator (if applicable)
**CI/CD PIPELINE**
An attacker with access to the CI/CD build system could compromise security in many ways. For example, a pipeline could be modified to expose the container registry or kubernetes cluster credentials. Another example is the pipeline could become hijacked such that it deploys malicious containers into the cluster instead of the intended one.
**CONTAINER REGISTRY**
An attacker with privileges to the trusted container registry could push images to the registry and overwrite existing, previously trusted images. For example, say your cluster is already running some image `<image>:v1.0`. An attacker with access to the registry could push a new image and overwrite the existing `<image>:v1.0` tag. Then, the next time the container starts, , it would run a compromised version of the image.
**GIT REPOSITORY**
The Git repository, in the context of GitOps, defines what resources will be installed into the cluster. In the worst case, an attacker with full access to the Git repository could push a new commit to the Git repo, updating a Deployment to run a malicious container in the cluster or createa resource such as Roles, RoleBindings, Ingresses, and NetworkPolicies.
**KUBERNETES CLUSTER**
Kubernetes cluster is the infrastructure platform that runs your application code. An attacker who has gained access to the cluster is arguably the worst-case scenario.
Traditionally, before GitOps, developers would generally require direct access to the Kubernetes cluster to manage and make changes to their environment. But with GitOps, direct access to the cluster is no longer strictly required since environment management can go through a new medium, Git.
## Patterns
Full access

Deployment repo access

Code access only
