kingjay66/anthos-security-blueprints

Implementation steps and assets for Google Cloud Anthos blueprints https://cloud.google.com/architecture/blueprints/anthos-security-blueprints-faq

Cloud Security Blueprints for Anthos

Introduction

This repository contains the deployable assets that are part of the Google Cloud Security blueprints for Anthos. The Google Cloud Security blueprints for Anthos are granular and address specific security postures.

The instructions and accompanying assets in this repo are for the following Google Cloud Security blueprints for Anthos:

• Enforcing Policies
• Enforcing locality restrictions for clusters on Google Cloud
• Restricting traffic
• Protecting API endpoints
• Managing secrets
• Auditing and monitoring for deviation from policy

The blueprints can be used in any combination. Note: If you need to constraint what regions your clusters can be deployed to the steps detailed in the Enforcing locality restrictions blueprint should be followed first before using any other Anthos security blueprint.

Config overview

This repository for the set of blueprints is to be used with a structured Anthos config management repo

Example Anthos config management Structured repo configuration:

── config-root/ # directory ACM monitors for policy
   ├── README.md
   ├── system/ # configs for the Operator
   ├── namespaces/ configs for namespaces and namespace-scoped objects. Structure determines namespace inheritance
   ├── cluster/ #  configs for cluster scoped objects
   |    | - # Put Your Policy Controller constraints here
   └── clusterregistry/ # configs for cluster selectors - limits which clusters a config applies to 
       ├── cluster.mycluster.yaml
       ├── clusterregistry.select-location-clusterx.yaml
       └── clusterregistry.select-prod.yaml

QuickStart

We recommend you read through the full README but if you just want to get started

1. Ensure the assumptions are met
2. Follow the steps in prerequisites
3. Configure your workstation environment
4. Clone the repo
5. Configure Cloud Platform IAM
6. Follow the deployment steps

If you have already implemented one of the Anthos specific blueprints for your Anthos clusters in this series you do not need to repeat the prerequisites and deployment steps described in this README

The blueprints outlined in this repo are additive so you can apply multiple blueprints to your clusters.

Follow through the detailed deployment steps for each individual blueprint by following the steps detailed in the README for the specific blueprint folder.

If you wish to start from an end to end example follow the steps outlined in the example README that mostly closely meets the security posture you wish to apply to your clusters.

Assumptions

• You have your Project and network configuration configured for your use case
• You have the appropriate IAM permissions to configure project resources
• You have an Anthos entitlement
• You have created your GKE On Google Cloud Clusters and/or your GKE on-premises clusters following the guidance in the applicable hardening guides
  • Hardening GKE on Google Cloud
  • Hardening GKE on-premises

Note: each blueprint in the series assumes you have Policy Controller installed which is a recommendation in the hardening guides

• Each cluster has the Anthos Config Management Operator installed
• Network policies are required and you created your cluster with the --enable-network-policy flag . This step provides you with the ability to implement firewall rules that restrict what traffic can flow between pods in a cluster
• You have defined the namespaces and labels required for the pods. This provides you with a name scope that allows you to work with policies and Kubernetes service accounts
• You have some familiarity with Anthos Config Management. If you have not used Anthos config Management before familiarise yourself by following the quickstart
• You are familiar with git

Prerequisites

Prepare your admin workstation

You can use Cloud Shell, a local machine or VM as your admin workstation

Tools for Cloud Shell as your Admin workstation

• kubectl
• nomos CLI for managing ACM across clusters
• Terraform >= 0.12.3

Tools for a local workstation as your Admin workstation

• Cloud SDK (gcloud CLI)
• kubectl
• nomos CLI for managing ACM across clusters
• Terraform >= 0.12.3

Installation instructions for Tools for your environment

Install Cloud SDK

This is pre installed if you are using Cloud Shell

The Google Cloud SDK is used to interact with your GCP resources. Installation instructions for multiple platforms are available online.

Install kubectl CLI

The kubectl CLI is used to interact with both Kubernetes Engine and kubernetes in general. Installation instructions for multiple platforms are available online.

Install the nomos CLI

Install the nomos CLI for managing ACM across clusters

Install Terraform

Terraform is used to automate the manipulation of cloud infrastructure. Its installation instructions are also available online. When configuring terraform for use with Google cloud create a service account as detailed in Getting started with the google provider

Authentication

After installing the gcloud SDK run gcloud init to set up the gcloud cli. When executing choose the correct region and zone

'gcloud init'

Ensure you are using the correct project . Replace my-project-name with the name of your project

Where the project name is my-project-name

gcloud config set project my-project-name

Deployment

Clone this repo

Important :If you are implementing multiple blueprints you only need to clone the repo once

In your terminal, clone this repo locally.

  $ git clone https://github.com/<GITHUB\_USERNAME>/xyz.git


  $ cd xyz/docs/

For production configurations ensure you have configured a centralised repo such as Cloud Source Repositories, GitHub, Gitlab for use with Anthos Config manager.

Configure ACM Operator with repo

Important : You only need to do this step once per cluster

The ACM Operator must be given read access to git and configured to read from a git repository. \

It is recommended to use a deploy key to authenticate the ACM Operator with git. Using a deploy key attaches the public part of the key directly to the repo rather than to a personal user account.

Create a ssh keypair and register the public key with your git hosting provider.

# create ssh key
ssh-keygen -t rsa -N '' -b 4096 -C <git_username> -f ~/.ssh/id_rsa.acm

# add key to your ssh agent
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa.acm

#### add contents of public key ~/.ssh/id_rsa.acm.pub to the repo in the github account you are using for your configs 
#### github.com > Your Profile > Repositories > Settings > Deploy Keys > Add Deploy Key
 Paste in contents   

# Set write access
Select Allow write access
Click Add Key

# verify access
ssh -i /path/to/private/key [email protected]
Hi <git username>! You've successfully authenticated, but GitHub does not provide shell access.

Add the private key to a secret "git-creds" in each of your clusters.

# create secret in operator
kubectl create secret generic git-creds \
--namespace=config-management-system \
--from-file=ssh=~/.ssh/id_rsa.acm

Each cluster's ACM operator must be configured to point to the config-root in anthos-security-blueprints

Each cluster has its own config in the [setup/] directory.

1. Create a copy of the template YAML file named mycluster-config-management.yaml in the setup/ folder of your cloned repo for each of the clusters you wish to apply any blueprints from this repo to naming the copy to reflect the name of your cluster
2. Update each of the copied files in setup/ to include your cluster names replacing 'mycluster' with your cluster name and the syncRepo git username with yours. For example, if your github username is [email protected] change each YAML file to include

        git:
         syncRepo: [email protected]:[email protected]/csp-config-management.git

If you are using another git repo amend accordingly

3. Remove the template file mycluster-config-management.yaml
4. Sync the ACM Operator for your clusters by repeating the following steps for each cluster

  # Get kubeconfig credentials for your cluster
  $ gcloud container clusters get-credentials <cluster name> --zone <cluster zone>
  # Ensure kubectl is using correct context
  $ kubectl config get-context
  # Apply the configuration to your cluster
  $ kubectl apply -f setup/<cluster name>.config-management.yaml

5. Confirm the sync was successful with nomos status

   For each cluster you should see the status set to SYNCED