Fix grammar, typos (#21)
Co-authored-by: Kevin Harris <Kevin.Harris@microsoft.com>
This commit is contained in:
Louis-Guillaume MORAND
GitHub
Родитель
11c8149086
Коммит
eadc1de3b5
14
SECURITY.md
14
SECURITY.md
|
|
@ -18,13 +18,13 @@ You should receive a response within 24 hours. If for some reason you do not, pl
|
|||
|
||||
Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue:
|
||||
|
||||
* Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
|
||||
* Full paths of source file(s) related to the manifestation of the issue
|
||||
* The location of the affected source code (tag/branch/commit or direct URL)
|
||||
* Any special configuration required to reproduce the issue
|
||||
* Step-by-step instructions to reproduce the issue
|
||||
* Proof-of-concept or exploit code (if possible)
|
||||
* Impact of the issue, including how an attacker might exploit the issue
|
||||
* Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
|
||||
* Full paths of source file(s) related to the manifestation of the issue
|
||||
* The location of the affected source code (tag/branch/commit or direct URL)
|
||||
* Any special configuration required to reproduce the issue
|
||||
* Step-by-step instructions to reproduce the issue
|
||||
* Proof-of-concept or exploit code (if possible)
|
||||
* Impact of the issue, including how an attacker might exploit the issue
|
||||
|
||||
This information will help us triage your report more quickly.
|
||||
|
||||
|
|
|
|||
|
|
@ -105,9 +105,9 @@ Technologies used:
|
|||
- Azure private DNS Zone
|
||||
- User Defined Routes
|
||||
|
||||
For more detailed documentation on how to set it up see here: https://docs.microsoft.com/en-gb/azure/aks/private-clusters
|
||||
For more detailed documentation on how to set it up see here: [https://docs.microsoft.com/en-gb/azure/aks/private-clusters](https://docs.microsoft.com/en-gb/azure/aks/private-clusters)
|
||||
|
||||
## Do you want to isolate multiple internal workloads against each other?
|
||||
## Do you want to isolate multiple internal workloads against each other ?
|
||||
|
||||
Objective:
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ There are different options for storing, managing and integrating secrets like c
|
|||
|
||||
## Native Kubernetes secrets
|
||||
|
||||
While the first option of using kubernetes native secret management has the obvious advantage of simplified operations it incurs the risk of credential leakage if your cluster is breached or someone with existing cluster access uses his privileges to access to retrieve connections strings and secrets. Therefore this approach requires the lockdown of access to secrets via RBAC and a good way of recycling and upgrading secret information on a regular basis. It assumes that RBAC is turned on and all workloads are deployed into dedicated namespaces, while users and service accounts are configured to use minimal privileges within their scope. Since secrets and certificates should not be part of the normal source control repository it requires an additional process to deploy and upgrade secret values and certificates.
|
||||
While the first option of using Kubernetes native secret management has the obvious advantage of simplified operations it incurs the risk of credential leakage if your cluster is breached or someone with existing cluster access uses his privileges to access to retrieve connections strings and secrets. Therefore this approach requires the lockdown of access to secrets via RBAC and a good way of recycling and upgrading secret information on a regular basis. It assumes that RBAC is turned on and all workloads are deployed into dedicated namespaces, while users and service accounts are configured to use minimal privileges within their scope. Since secrets and certificates should not be part of the normal source control repository it requires an additional process to deploy and upgrade secret values and certificates.
|
||||
|
||||
Tradeoffs to be made:
|
||||
|
||||
|
|
@ -20,26 +20,26 @@ Tradeoffs to be made:
|
|||
|
||||
## KMS plugin for Azure KeyVault
|
||||
|
||||
The KMS plugin for Azure KeyVault allows encryption of data at rest that is stored in *etcd*. This scenario enabled the encryption of secrets and certificates with an encryption key that is stored in an instance of Azure KeyVault which is under the control of the customer. It ensures that normal Kubernetes objects can be used and does not make any assumptions on implementation patterns for the applications. While AKS ensures encryption at rest of the data in etcd, it does not allow the usage of a customer managed key. Since AKS does not support the usage of the KMS plugin, this means that the usage of KMS plugin forces the deployment of a cluster on unmanaged IaaS or AKS-Engine, where customers can fully control and own the configuration of etcd.
|
||||
The KMS plugin for Azure KeyVault allows encryption of data at rest that is stored in *etcd*. This scenario enabled the encryption of secrets and certificates with an encryption key that is stored in an instance of Azure KeyVault which is under the control of the customer. It ensures that normal Kubernetes objects can be used and does not make any assumptions on implementation patterns for the applications. While AKS ensures encryption at rest of the data in etcd, it does not allow the usage of a customer-managed key. Since AKS does not support the usage of the KMS plugin, this means that the usage of KMS plugin forces the deployment of a cluster on unmanaged IaaS or AKS-Engine, where customers can fully control and own the configuration of etcd.
|
||||
|
||||
**For further documentation click [here](https://github.com/Azure/kubernetes-kms)**
|
||||
|
||||
Tradeoffs to be made:
|
||||
|
||||
- KMS plugin allows to ensure that all configuration data and secrets in *etcd* are encrypted with a customer managed key
|
||||
- KMS plugin allows to ensure that all configuration data and secrets in *etcd* are encrypted with a customer-managed key
|
||||
- KMS does not require and changes to the application - native Kubernetes can be used
|
||||
- KMS plugin is **not** supported with managed AKS
|
||||
- KMS plugin does not support key rotation scenarios.
|
||||
|
||||
## Sealed Secrets
|
||||
|
||||
The objective for using sealed secrets is to allow for an automated process to frequently replace secret values in Kubernetes. Therefore the cleartext values are encrypted before deployment into a Kubernetes custom resource and deployed into the right namespaces in the cluster in encrypted format. After deployment a custom controller will read the encrypted value and create an unencrypted secret within the same namespace that can now be used as expected by the pods. This process allows decoupling of responsibilities and a secure delivery mechanism for the deployment of secrets while ensuring compatibilitiy with the Kubernetes object model.
|
||||
The objective for using sealed secrets is to allow for an automated process to frequently replace secret values in Kubernetes. Therefore the cleartext values are encrypted before deployment into a Kubernetes custom resource and deployed into the right namespaces in the cluster in an encrypted format. After deployment a custom controller will read the encrypted value and create an unencrypted secret within the same namespace that can now be used as expected by the pods. This process allows decoupling of responsibilities and a secure delivery mechanism for the deployment of secrets while ensuring compatibility with the Kubernetes object model.
|
||||
|
||||
**For further documentation click [here](https://github.com/bitnami-labs/sealed-secrets)**
|
||||
|
||||
Tradeoffs to be made:
|
||||
|
||||
- Sealed secrets allows separation of concerns and permissions through automated process
|
||||
- Sealed secrets allows separation of concerns and permissions through an automated process
|
||||
- Sealed secrets uses automatable tools that are only handling encrypted values
|
||||
- Sealed secrets requires a custom resource definition and custom tools to handle de/encryption
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ Tradeoffs to be made:
|
|||
The usage of the Azure KeyVault Flexvolume ensures that all secret values are stored outside of the Kubernetes cluster and can be updated through an external process independant of the application deployments. All secret values will be retrieved for each pod after it has successfully authentication to the KeyVault and mounted into a memory drive which will not be persisted inside the cluster. In combination with the AAD Pod Identity this allows for a very fine granular process of granting permissions to individual applications and changing them frequently. Since only memory values can be mounted into a pod this does not allow the usage of environment variables that are injected from Azure KeyVault values.
|
||||
|
||||
For further documentation see: [flexvol](https://github.com/Azure/kubernetes-keyvault-flexvol)
|
||||
After Kubernetes 1.16+ the same behaviour will be achievable using the secret store driver: [CSI driver](https://github.com/Azure/secrets-store-csi-driver-provider-azure)
|
||||
After Kubernetes 1.16+ the same behavior will be achievable using the secret store driver: [CSI driver](https://github.com/Azure/secrets-store-csi-driver-provider-azure)
|
||||
|
||||
Tradeoffs to be made:
|
||||
|
||||
|
|
|
|||
|
|
@ -193,6 +193,6 @@ az network public-ip create -g $RG -n $AGPUBLICIP_NAME -l $LOC --sku "Standard"
|
|||
* [Configure AKS with Azure CNI](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni)
|
||||
* [Plan IP Addressing with Azure CNI](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni#plan-ip-addressing-for-your-cluster)
|
||||
* [Using Multiple Node Pools](https://docs.microsoft.com/en-us/azure/aks/use-multiple-node-pools)
|
||||
* [Create nginx Ingress Controller](https://docs.microsoft.com/en-us/azure/aks/ingress-basic)
|
||||
* [Create Nginx Ingress Controller](https://docs.microsoft.com/en-us/azure/aks/ingress-basic)
|
||||
* [Create HTTPS Ingress Controller](https://docs.microsoft.com/en-us/azure/aks/ingress-tls)
|
||||
* [Integrate ILB with Firewall](https://docs.microsoft.com/en-us/azure/firewall/integrate-lb)
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ After forking the repo you'll need to clone it locally.
|
|||
git clone https://github.com/<user_name>/sg-aks-workshop
|
||||
```
|
||||
|
||||
You'll also need to create a github personal access token that will be used to access the git repo from Flux. You can find the instructions on creating a Github personal access token below:
|
||||
You'll also need to create a Github personal access token that will be used to access the git repo from Flux. You can find the instructions on creating a Github personal access token below:
|
||||
|
||||
[Github PAT Instructions](https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line)
|
||||
|
||||
|
|
@ -136,7 +136,7 @@ You'll notice once your cluster is provisioned you'll also have the following de
|
|||
|
||||
* __Network Policy Rules__ - The network policies will restrict communication between different teams' namespace, to limit the exposure of access between namespaces.
|
||||
|
||||
* __Gatekeeper Policies__ - Allows a custom admission control to define policies to meet the company's compliance and governance needs. For example, if you want to only allow users to deploy internal load balancers, then gatekeeper can enforce it based on the policy that has been set.
|
||||
* __Gatekeeper Policies__ - Allows a custom admission control to define policies to meet the company's compliance and governance needs. For example, if you want to only allow users to deploy internal load balancers, then Gatekeeper can enforce it based on the policy that has been set.
|
||||
|
||||
* __Falco Rules__ - Provides runtime security to enforce policy across all your Kubernetes clusters. For example, one of the policies will inform you based on users performing an "exec" command against a container.
|
||||
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ You'll see a dashboard like the one below when selecting your cluster
|
|||
|
||||
|
||||
|
||||
If you select __Allocation__ on the left side you can dig down into the namespace cost of your resources. It will show the cost for CPU, Memory, Persistent Volumes, and Network. It gets the data from Azure pricing, but you can also set custom cost of the resources.
|
||||
If you select __Allocation__ on the left side you can dig down into the namespace cost of your resources. It will show the cost for CPU, Memory, Persistent Volumes, and Network. It gets the data from Azure pricing, but you can also set a custom cost of the resources.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ This section describes who does what in the organization (e.g. who is using Data
|
|||
* Security team: Responsible for reviewing individual Azure services as Lines of Business want to use them from a controls/visibility perspective and maintain a "service catalog" of the required configuration of services that can be used based on data sensitivity (a service catalog). Such configurations may include required authentication method, authorization configuration, network connectivity to/from, encryption configuration and encryption key management, and monitoring requirements for any proposed service. They are responsible for translating these into operational controls as well (e.g. Azure Policies). They are responsible for reviewing proposed Azure architectures to verify they meet Contoso's security requirements as part of the Cloud architecture's SDL process. They are responsible for evaluating and presenting a risk to the Lines of Business when a proposed architecture falls outside of established services/architectures.
|
||||
* Security Operations (SecOps) team: Responsible for the operationalizing and operation of the security of the Azure environment for Contoso. This includes monitoring (using native tools and their SIEM) as well as Incident response planning.
|
||||
* Compliance team: Responsible for ensuring regulatory and industry compliance standards are met. They work closely with the Security team and Cloud architecture team to flow down control and monitoring/auditing requirements and review designs to ensure they can be met.
|
||||
* Identity team: Responsible for Identity and Access Management for the Azure environment, working closely with the Security and Cloud Architecture team for use of AAD, Role Based Access Controls, IAM segmentation, use of and monitoring service principles for service access, application level access (Internal, B2B, and B2C), and VM level access/Roles. They work closely with the security and SecOps team to ensure requirements and appropriate controls/monitoring are in place across their responsible areas.
|
||||
* Identity team: Responsible for Identity and Access Management for the Azure environment, working closely with the Security and Cloud Architecture team for use of AAD, Role Based Access Controls (RBAC), IAM segmentation, use of and monitoring service principles for service access, application-level access (Internal, B2B, and B2C), and VM level access/Roles. They work closely with the security and SecOps team to ensure requirements and appropriate controls/monitoring are in place across their responsible areas.
|
||||
* Networking team: Responsible for all networking for Contoso including control/monitoring of physical and virtual networking systems. They are solely responsible for VNETs in Azure, Azure networking services (both first and third party) as well as connectivity to/from Corpnet.
|
||||
|
||||
## Requirements
|
||||
|
|
|
|||
|
|
@ -45,32 +45,32 @@ kubectl get ns -w
|
|||
|
||||
## Resource Management
|
||||
|
||||
One of the important task of day 2 operations is resource management. Resource Management consist of maintaining adequate resources to serve your workloads. Kubernetes provides built in mechanisms to provide both soft and hard limits on CPU and Memory. It's important to understand how these request and limits work as it will ensure you provide adequate resource utilization for your cluster.
|
||||
One of the important task of day 2 operations is resource management. Resource Management consists of maintaining adequate resources to serve your workloads. Kubernetes provides built-in mechanisms to provide both soft and hard limits on CPU and Memory. It's important to understand how these request and limits work as it will ensure you provide adequate resource utilization for your cluster.
|
||||
|
||||
__Requests__ are what the container is guaranteed to get. If a container requests a resource then Kubernetes will only schedule it on a node that satisfies the request. __Limits__, on the other hand, ensure a container never goes above a certain configured value. The container is only allowed to go up to this limit, and then it is restricted.
|
||||
|
||||
When a container does hit the limit there is different behavior from when it hits a memory limit vs a CPU limit. With a memory limit the container will be killed and you'll see an "Out Of Memory Error". When a CPU limit is hit it will just start throttling the CPU vs restarting the container.
|
||||
|
||||
It's also important to understand how Kubernetes assigns QoS classes when scheduling pods, as it hav an effect on pod scheduling and eviction. Below is the different QoS classes that can be assigned when a pod is scheduled:
|
||||
It's also important to understand how Kubernetes assigns QoS classes when scheduling pods, as it has an effect on pod scheduling and eviction. Below is the different QoS classes that can be assigned when a pod is scheduled:
|
||||
|
||||
- **QoS class of Guaranteed:**
|
||||
- Every Container in the Pod must have a memory limit and a memory request, and they must be the same.
|
||||
- Every Container in the Pod must have a CPU limit and a CPU request, and they must be the same.
|
||||
|
||||
- **QoS class of Burstable**
|
||||
- The Pod does not meet the criteria for QoS class Guaranteed.
|
||||
- The Pod does not meet the criteria for QoS class **Guaranteed*.
|
||||
- At least one Container in the Pod has a memory or CPU request.
|
||||
|
||||
- **QoS class of Best Effort**
|
||||
- For a Pod to be given a QoS class of BestEffort, the Containers in the Pod must not have any memory or CPU limits or requests.
|
||||
|
||||
Below shows a diagram depicting QoS based on request and limits.
|
||||
Below shows a diagram depicting QoS based on requests and limits.
|
||||
|
||||
|
||||
|
||||
**Failure to set limits for memory on pods can lead to a single pod starving the cluster of memory.**
|
||||
|
||||
If you want to ensure every pod get at least a default request/limit, you can set a **LimitRange** on a namespace. If you preform the following command you can see in our cluster we have a LimitRange set on the Dev namespace.
|
||||
If you want to ensure every pod gets at least a default request/limit, you can set a **LimitRange** on a namespace. If you perform the following command you can see in our cluster we have a LimitRange set on the Dev namespace.
|
||||
|
||||
```bash
|
||||
# Check Limit Ranges in Dev Namespace
|
||||
|
|
@ -120,9 +120,9 @@ Monitoring disk space a critical part of keeping any Kubernetes cluster alive. E
|
|||
Here is an example of disk capacity
|
||||
|
||||
|
||||
Disk throttling
|
||||
Disk throttling
|
||||
|
||||
From the Insights portal you can also view the node disk capacity.
|
||||
From the Insights portal you can also view the node disk capacity.
|
||||
|
||||
|
||||
|
||||
|
|
@ -134,7 +134,7 @@ In the next section, we'll dive into how to view live logs, create log query, an
|
|||
|
||||
## Live Logs
|
||||
|
||||
Live logs are nice way to see logs being emitted from STDOUT/STDERR of a container. You can give developers access to the live logging, so they can live debug issues happening with their application. This allows you to limit their exposure to using __kubectl__ for application issues.
|
||||
Live logs are a nice way to see logs being emitted from STDOUT/STDERR of a container. You can give developers access to the live logging, so they can live debug issues happening with their application. This allows you to limit their exposure to using __kubectl__ for application issues.
|
||||
|
||||
To access the live logs you will need to navigate to the Insights section of the AKS Cluster
|
||||
|
||||
|
|
@ -172,17 +172,17 @@ Perf
|
|||
| where CounterName == 'cpuUsageNanoCores'
|
||||
| summarize UsageValue = max(CounterValue) by bin(TimeGenerated, 1m), Computer, InstanceName, CounterName
|
||||
| project-away CounterName
|
||||
| join kind = fullouter
|
||||
| join kind = fullouter
|
||||
(Perf
|
||||
| where ObjectName == 'K8SContainer'
|
||||
| where CounterName == 'cpuRequestNanoCores'
|
||||
| summarize RequestValue = max(CounterValue) by bin(TimeGenerated, 1m), Computer, InstanceName, CounterName
|
||||
| project-away CounterName
|
||||
) on Computer, InstanceName, TimeGenerated
|
||||
| project TimeGenerated = iif(isnotempty(TimeGenerated), TimeGenerated, TimeGenerated1),
|
||||
| project TimeGenerated = iif(isnotempty(TimeGenerated), TimeGenerated, TimeGenerated1),
|
||||
Computer = iif(isnotempty(Computer), Computer, Computer1),
|
||||
InstanceName = iif(isnotempty(InstanceName), InstanceName, InstanceName1),
|
||||
UsageValue = iif(isnotempty(UsageValue), UsageValue, 0.0),
|
||||
UsageValue = iif(isnotempty(UsageValue), UsageValue, 0.0),
|
||||
RequestValue = iif(isnotempty(RequestValue), RequestValue, 0.0)
|
||||
| extend ConsumedValue = iif(UsageValue > RequestValue, UsageValue, RequestValue)
|
||||
) on InstanceName, TimeGenerated
|
||||
|
|
@ -191,7 +191,7 @@ Perf
|
|||
|
||||
If we run that query with the changed cluster name you should see something a la the following. In case you have multi namespaces it will also be shown.
|
||||
|
||||
|
||||
|
||||
|
||||
Here is another example where we do it based on Memory per namespace
|
||||
|
||||
|
|
@ -219,7 +219,7 @@ ContainerInventory
|
|||
|
||||
## Cluster Upgrade With Node Pools
|
||||
|
||||
With nodepools available in AKS, we have the ability to decouple the Control Plane upgrade from the nodes upgrade, and we will start by upgrading our control plane.
|
||||
With nodepools available in AKS, we can decouple the Control Plane upgrade from the nodes upgrade, and we will start by upgrading our control plane.
|
||||
|
||||
**Note** Before we start, at this stage you should:
|
||||
1- Be fully capable of spinning up your cluster and restore your data in case of any failure (check the backup and restore section)
|
||||
|
|
@ -268,7 +268,7 @@ Since control-plane-only argument is specified, this will upgrade only the contr
|
|||
....
|
||||
```
|
||||
|
||||
**Note** The Control Plane can support N-2 kubelet on the nodes, which means 1.15 Control Plane supports 1.14, and 1.12 Kubelet. Kubelet can't be *newer* than the Control Plane. more information can be found [here](https://kubernetes.io/docs/setup/release/version-skew-policy/#kube-apiserver)
|
||||
**Note** The Control Plane can support N-2 kubelet on the nodes, which means 1.15 Control Plane supports 1.14, and 1.13 Kubelet. Kubelet can't be *newer* than the Control Plane. more information can be found [here](https://kubernetes.io/docs/setup/release/version-skew-policy/#kube-apiserver)
|
||||
|
||||
Let's add a new node pool with the desired version "1.15.7"
|
||||
|
||||
|
|
|
|||
|
|
@ -12,11 +12,11 @@ The end result on the front-end should display what type of fruit image was proc
|
|||
|
||||
Before we get into setting up the application, let's have a quick discussion on what container development looks like for the customer. No development environment is the same as it is not a one size fits all when it comes to doing development. Computers, OS, languages, and IDEs to name a few things are hardly ever the same configuration/setup. And if you throw the developer themselves in that mix it is definitely not the same.
|
||||
|
||||
As a result, different users work in different ways. The following are just a few of the **inner devops loop** tools that we are seeing in this eco-system, feel free to try any of them out and let us know what you think. And if it hits the mark.
|
||||
As a result, different users work in different ways. The following are just a few of the **inner DevOps loop** tools that we are seeing in this eco-system, feel free to try any of them out and let us know what you think. And if it hits the mark.
|
||||
|
||||
### Tilt
|
||||
|
||||
Tilt is a CLI tool used for local continuous development of microservice applications. Tilt watches your files for edits with tilt up, and then automatically builds, pushes, and deploys any changes to bring your environment up-to-date in real-time. Tilt provides visibility into your microservices with a command-line UI. In addition to monitoring deployment success, the UI also shows logs and other helpful information about your deployments.
|
||||
Tilt is a CLI tool used for local continuous development of microservice applications. Tilt watches your files for edits with tilt-up, and then automatically builds, pushes, and deploys any changes to bring your environment up-to-date in real-time. Tilt provides visibility into your microservices with a command-line UI. In addition to monitoring deployment success, the UI also shows logs and other helpful information about your deployments.
|
||||
|
||||
Click [here](https://github.com/windmilleng/tilt) for more details and to try it out.
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ docker push ${PREFIX}acr.azurecr.io/imageclassifierworker:v1
|
|||
|
||||
## Image Vulnerability Scanning and Management
|
||||
|
||||
One of the most important things an organization can do when adopting Containers is good image management hygiene. This means that images should be scanned prior to being deployed to a cluster. **The old saying goes, "Garbage In, Garbage Out", meaning if you deploy unsecure images to the container registry then the cluster will be deploying unsecure and potentially dangerous images.**
|
||||
One of the most important things an organization can do when adopting Containers is good image management hygiene. This means that images should be scanned prior to being deployed to a cluster. **The old saying goes, "Garbage In, Garbage Out", meaning if you deploy unsecured images to the container registry then the cluster will be deploying unsecured and potentially dangerous images.**
|
||||
|
||||
* It is critical to scan images for vulnerabilities in your environment. We recommending using a Enterprise-grade tool such as [Aqua Security](https://www.aquasec.com/products/aqua-container-security-platform) or [Twistlock](https://www.twistlock.com/why-twistlock) or [SysDig Secure](https://sysdig.com/products/secure/).
|
||||
|
||||
|
|
|
|||
|
|
@ -6,27 +6,17 @@ Now that we know the customer scenario and understand what needs to be implement
|
|||
|
||||
## Security Control Lifecycle in the Cloud
|
||||
|
||||
A primary consideration when discussing the Cloud Native approach to Security and Governance is the dynamic nature of the cloud itself. In traditional enterprises, environments tend to be relatively stable with both preventative and detective technical controls in place. In addition, the organizational model tends to align with traditional IT functions such as identity, networking and machine/VM OS management; therefore, a security and compliance team would typically handle relatively infrequent changes to the overall infrastructure, controls, and monitoring required to achieve the security and risk objectives of the enterprise.
|
||||
One of the first things to understand when talking about Cloud Native Security and Governance is that the cloud can be very dynamic where as most enterprises are used to having relatively stable environments that include both technical preventative and detective controls in place as well as a structured organizational model that aligns with traditional IT functions such as Identity, Networking, machine and VM OS management. The security and compliance team had to work with relatively infrequent changes to the overall structure and infrastructure and the controls and monitoring required to achieve the enterprises security and risk objectives. With the adopting the cloud and also in adopting dev/ops models, security ends up having to adapt to operate as part of those changes in order to not become an impediment to the business and progress. Much of that includes how to create the right roles and responsibilities (people processes) as well as automation and technical tools such as scanning/testing and infrastructure as code as part of a DevOps pipeline to enable innovation and time to delivery while still ensuring security requirements can be met.
|
||||
|
||||
With the adoption of the cloud and also the adoption of devops models, security must adapt and evolve in order to support these changes, rather than allowing legacy approaches to impede technical innovation. In order to enable this transformation while maintaining system integrity, the right roles and responsibilities (people and processes) need to be created alongside the adoption of automation and technical tooling such as scanning/testing and infrastructure as code in the devops pipeline.
|
||||
**The temptation and typical path most enterprises take is starting off by doing what they do today. In some aspects, you can but in others, no. The key take-a-way is that if you simply try and do exactly what you are doing today on-prem in the Cloud, you will fail.** Adopting the cloud is an opportunity to update skills, learn, increase the organization's security posture and position security to be an enabler rather than a blocker by streamlining security as part of the development to production process. If you use 10-20-years-old tools and processes, you are simply going to inherit/introduce the same 10-20-years-old security challenges, problems and frustrations to the business. This is your chance to start fresh.
|
||||
|
||||
**Initially, most enterprises start off in this new world by trying to do exactly what they do today. While certain things will remain consistent, many others will require change. Keep in mind: if you try and do exactly what you are doing on-premises today when you move to the the Cloud, you will fail.**
|
||||
So how is that done? It starts with an understanding of the cloud, what services are available, what controls are available, what visibility is available, how do I operate it, what security tools and governance tools are available and how can I leverage them as part of a process/system so lines of business can be more agile, a modern dev-ops model, and I can ensure that security and compliance requirements can be met.
|
||||
|
||||
Migrating to the cloud is an opportunity to learn, update skills, increase an organization's security posture and position security as an enabler-rather than a blocker- through the streamlining of security within the development to production process. If you use 10-20 year old tools and processes, you are simply going to inherit/introduce the same 10-20 year old security challenges, problems and frustrations into your cloud journey. Consider this a chance to start fresh!
|
||||
|
||||
So how can we execute on this clean slate? We need to start with an understanding of the following:
|
||||
- Cloud fundamentals
|
||||
- Availability of services, tools, controls and visibility within the cloud
|
||||
- Cloud operations
|
||||
- How to integrate services and tools into the devops process that meet security and governance requirements
|
||||
|
||||
It's often easiest to start with an existing process framework/lifecycle in order to establish security controls and manage/operationalize the controls themselves. For the former, many customers use common security control frameworks and standards such as NIST 800-53, ISO, CIS benchmarks, HIPAA/HITRUST, etc. These can help establish a comprehensive framework and often provide guidance on how to establish, document, and/or audit security controls and processes.
|
||||
|
||||
When it comes to managing/operationalizing security controls, especially in relation to the cloud and devops, it can be useful to look at models like SDL processes that treat security controls as if they are traditional organizational assets like lifecycle management (see below).
|
||||
It's often easiest to start with a framework/lifecycle from a process perspective in both establishing security controls as well as how to manage/operationalize the controls themselves. For the former, many customers use common security control frameworks and standards such as NIST 800-53, ISO, CIS benchmarks, HIPAA/HITRUST, etc. These can help establish a comprehensive framework and often guidance to help establish, document, and/or audit security controls and processes. When it comes to managing/operationalizing security controls, in particular when it comes to things like the Cloud and DevOps, it can be useful to look at a variety of models including SDL processes that include cloud and dev/ops, approaches and models like treating security controls like assets like any others in an organization including lifecycle management (see below).
|
||||
|
||||
|
||||
|
||||
The big takeaway from the diagram is that security controls should be treated like other important assets in an organization; this approach should start with Source Control. Similar to how infrastucture has moved towards Infrastructure-as-Code which enables the creation of resources on demand, security should also be moving in the same direction.
|
||||
The big take-a-way from the diagram is that security controls should be treated like other important assets in an organization, it should start with Source Control. Similar to how Infrastructure has moved towards Infrastructure as Code and having the ability to recreate resources on-demand, Security needs to start moving in the same direction.
|
||||
|
||||
## Next Steps
|
||||
|
||||
|
|
|
|||
|
|
@ -47,15 +47,15 @@ exit
|
|||
|
||||
## Kubernetes Audit Logs
|
||||
|
||||
There is an overwhelming need for organizations to capture all data that they can in case they need it. The Kubernetes audit logs falls into this bucket. It produces a ton of data that chews up storage, and most organizations are not sure what to do with.
|
||||
There is an overwhelming need for organizations to capture all data that they can in case they need it. The Kubernetes audit logs fall into this bucket. It produces a ton of data that chews up storage, and most organizations are not sure what to do with.
|
||||
|
||||
So what do we do? We highly encourage organizations to only capture the data that they need to help reduce costs as well as optimize around analytics that need to be done. The less data that needs to be processed, the less compute that is needed, which means less cost. So, do you really need the audit logs?
|
||||
|
||||
Ok, you get it, or you don't buy into selectively capturing data. Your orgnization needs to capture all of the data because you don't know what you don't know.
|
||||
Ok, you get it, or you don't buy into selectively capturing data. Your organization needs to capture all of the data because you don't know what you don't know.
|
||||
|
||||
### Capturing & Storing AKS Audit Logs
|
||||
|
||||
So how do I capture those kubernetes audit logs and where should they be put? Directing the logs to Azure Monitor for Containers gets really expensive, really fast, due to the sheer volume of data records that are captured. Considering that most organizations are not 100% sure if they need the logs or not, and to keep costs to a minimum, the guidance is to direct the audit logs to Azure Storage.
|
||||
So how do I capture those Kubernetes audit logs and where should they be put? Directing the logs to Azure Monitor for Containers gets really expensive, really fast, due to the sheer volume of data records that are captured. Considering that most organizations are not 100% sure if they need the logs or not, and to keep costs to a minimum, the guidance is to direct the audit logs to Azure Storage.
|
||||
|
||||
* Click [Enable Kubernetes Logs](https://docs.microsoft.com/en-us/azure/aks/view-master-logs) for more details and direct **kube-audit** logs to an Azure Storage Account, **NOT Log Analytics**.
|
||||
|
||||
|
|
|
|||
|
|
@ -42,12 +42,12 @@ So you did not buy into the statements above, or maybe your organization has bou
|
|||
|
||||
**For the purposes of this workshop, our focus is around securing communication between services, nothing else. Given that is our requirement, Linkerd was chosen for its focus on performance and minimizing impact on cluster resources.** The following sections will demonstrate Linkerd as we have found it straight forward, easy to use, and able to get up and running in minutes.
|
||||
|
||||
* Click [here](https://linkerd.io/2/getting-started/) to get the linkerd cli installed if you have not already.
|
||||
* Click [here](https://linkerd.io/2/getting-started/) to get the Linkerd CLI installed if you have not already.
|
||||
* Click [here](https://linkerd.io/2/reference/architecture/) for an architectural overview.
|
||||
|
||||
### Quick Dive into Linkerd
|
||||
|
||||
The first thing we will check is to make sure linkerd is running correctly, this is done by checking the control plane and namespaces for any errors using the linkerd cli.
|
||||
The first thing we will check is to make sure Linkerd is running correctly, this is done by checking the control plane and namespaces for any errors using the Linkerd CLI.
|
||||
|
||||
```bash
|
||||
# Check Version
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче