Skip to content

Commit

Permalink
Prep sample content
Browse files Browse the repository at this point in the history
Signed-off-by: Chris Abraham <cjyabraham@gmail.com>
  • Loading branch information
cjyabraham committed Feb 18, 2024
1 parent 7f44275 commit b003ed4
Show file tree
Hide file tree
Showing 15 changed files with 18 additions and 306 deletions.
2 changes: 1 addition & 1 deletion website/assets/icons/logo.svg
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
2 changes: 1 addition & 1 deletion website/assets/scss/_header.scss
Original file line number Diff line number Diff line change
Expand Up @@ -105,7 +105,7 @@
}
}
&.active span:after {
background-color: #00c3a0a6;
background-color: #dfcb1cab;
}
}
// Topnav dropdown.
Expand Down
18 changes: 9 additions & 9 deletions website/config.toml
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
baseURL = "https://tag-security.cncf.io/"
title = "CNCF TAG Security"
baseURL = "https://tag-observability.cncf.io/"
title = "CNCF TAG Observability"

# Language settings
contentDir = "content"
Expand Down Expand Up @@ -47,8 +47,8 @@ anchor = "smart"

[languages]
[languages.en]
title = "CNCF TAG Security"
description = "TAG Security facilitates collaboration to discover and produce resources that enable secure access, policy control, and safety for operators, administrators, developers, and end-users across the cloud native ecosystem."
title = "CNCF TAG Observability"
description = "TAG Observability facilitates collaboration to discover and produce resources that enable secure access, policy control, and safety for operators, administrators, developers, and end-users across the cloud native ecosystem."
languageName ="English"
# Weight used for sorting.
weight = 1
Expand All @@ -72,7 +72,7 @@ copyright = "CNCF"
privacy_policy = "https://policies.google.com/privacy"

# First one is picked as the Twitter card image if not set on page.
image = "https://tag-security.cncf.io/images/cncf-security-share.jpg"
image = "https://tag-observability.cncf.io/images/observability-social.jpg"

# Menu title if your navbar has a versions selector to access old versions of your site.
# This menu appears only if you have at least one [params.versions] set.
Expand All @@ -90,7 +90,7 @@ version = "0.0"

# A link to latest version of the docs. Used in the "version-banner" partial to
# point people to the main doc site.
url_latest_version = "https://security.cncf.io"
url_latest_version = "https://observability.cncf.io"

# Google Custom Search Engine ID. Remove or comment out to disable search.
gcs_engine_id = "94caa124b871f4944"
Expand All @@ -107,7 +107,7 @@ prism_syntax_highlighting = false

# Repository configuration (URLs for in-page links to opening issues and suggesting changes)
[params.github]
repo = "https://github.com/cncf/tag-security"
repo = "https://github.com/cncf/tag-observability"
branch = "main"
subdir = "website"

Expand All @@ -133,8 +133,8 @@ sidebar_search_disable = false
[params.ui.feedback]
enable = true
# The responses that the user sees after clicking "yes" (the page was helpful) or "no" (the page was not helpful).
yes = 'Glad to hear it! Please <a href="https://github.com/cncf/tag-security/issues/new">tell us how we can improve</a>.'
no = 'Sorry to hear that. Please <a href="https://github.com/cncf/tag-security/issues/new">tell us how we can improve</a>.'
yes = 'Glad to hear it! Please <a href="https://github.com/cncf/tag-observability/issues/new">tell us how we can improve</a>.'
no = 'Sorry to hear that. Please <a href="https://github.com/cncf/tag-observability/issues/new">tell us how we can improve</a>.'

# Adds a reading time to the top of each doc.
# If you want this feature, but occasionally need to remove the Reading time from a single page,
Expand Down
46 changes: 3 additions & 43 deletions website/content/_index.md
Original file line number Diff line number Diff line change
@@ -1,50 +1,10 @@
---
title: "CNCF TAG Security"
title: "CNCF TAG Observability"
toc_hide: true
---

<div class="row mt-5 mb-3">
<div class="col-lg-6">
<div class="lead">
TAG Security champions collaborative initiatives to discover and produce resources that bolster security protocols, access management, and policy enforcement, thereby catering to security practioners ranging from open source project maintainers to end user organization personnel, such as operators, administrators, and developers within the cloud native ecosystem.
</div>
</div>
<div class="col-lg-6 text-center">
<img src="/images/sig-security-icon-color.svg" alt="Tag Security logo" style="max-width: 200px;">
</div>
<div class="lead">
TAG Observability focuses on topics pertaining to the observation of cloud native workloads. Additionally, it produces supporting material and best practices for end-users and provides guidance and coordination for CNCF projects working within the TAG’s scope.
</div>


The TAG produces guidance for and gathers feedback from security engineering and
developers and provides guidance and coordination to CNCF projects in the TAG's
technical domains.

- [TAG Charter](https://github.com/cncf/toc/blob/main/tags/security.md)
- [Calendar of Meetings and Events](https://calendar.google.com/calendar/u/0?cid=MGI4dTVlbDh0YTRzOTN0MmNtNzJ0dXZoaGtAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ))
- [Invite yourself to the CNCF Slack](https://slack.cncf.io/)
- [Mailing list](https://lists.cncf.io/g/cncf-tag-security/topics)

<p class="mt-5"><img src="/images/man-using-laptop.jpg" alt="Man working on computer"></p>


## Meetings

Given the global spread of our TAG members, we conduct two series of regular meetings to accommodate the various time zones and ensure the inclusion of our entire global community. We have carefully scheduled our meetings to cater to various time zones.

For our members in North and South America, we host weekly sessions each Wednesday at 10 am (UTC-7). To participate, simply use the following Zoom link: https://zoom.us/j/99809474566. The meeting ID is 998 0947 4566. Meanwhile, participants from Europe, the Middle East, and Africa (EMEA) can join bi-weekly meetings on Wednesdays at 1 pm UTC+0, which adjusts to UTC+1 when daylight saving time is in effect. Join us through this Zoom link: https://zoom.us/j/99917523142, with the meeting ID: 999 1752 3142. To find the corresponding time in your local area, please see your timezone [here](https://time.is/). This dual schedule ensures that no matter where you are, you'll have a place in our conversations.

We invite you to mark your calendars and join the dialogue. For your convenience, all meetings are listed on the main [CNCF calendar](https://www.cncf.io/calendar/) as well as the [TAG Security Calendar](https://calendar.google.com/calendar/u/0?cid=MGI4dTVlbDh0YTRzOTN0MmNtNzJ0dXZoaGtAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ). These calendars are updated regularly to ensure that you stay informed of all upcoming meetings and events.


## Leads

- [Justin Cappos](https://github.com/JustinCappos) (Technical Leader)
- [Pushkar Joglekar](https://github.com/PushkarJ) (Chair)
- [Michael Lieberman](https://github.com/mlieberman85) (Technical Leader)
- [Andrew Martin](https://github.com/sublimino) (Chair)
- [Marina Moore](https://github.com/mnm678) (Chair)
- [Ash Narkar](https://github.com/ashutosh-narkar) (Technical Leader)
- [Ragashree Shekar](https://github.com/ragashreeshekar) (Technical Leader)
- [Andrés Vega](https://github.com/anvega) (Technical Leader)


4 changes: 2 additions & 2 deletions website/content/about/_index.md
Original file line number Diff line number Diff line change
@@ -1,10 +1,10 @@
---
title: About TAG Security
title: About TAG Observability
linkTitle: About
toc_hide: true
menu:
main:
weight: 20
description: More about TAG Security
description: More about TAG Observability
---

2 changes: 1 addition & 1 deletion website/content/about/projects.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
---
title: Projects
description: TAG Security projects.
description: TAG Observability projects.
---
9 changes: 0 additions & 9 deletions website/content/assessments/_index.md

This file was deleted.

5 changes: 0 additions & 5 deletions website/content/assessments/assessment-1.md

This file was deleted.

52 changes: 1 addition & 51 deletions website/content/blog/clusters-for-all-cloud-tenants.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,54 +4,4 @@ date: 2022-06-02 13:04:00 +0200
author: Josh Gavant
---

A decision which faces many large organizations as they adopt cloud architecture is how to provide isolated spaces within the same environments and clusters for various teams and purposes. For example, marketing and sales applications may need to be isolated from an organization's customer-facing applications; and development teams building any app usually require extra spaces for tests and verification.

## Namespace as unit of tenancy

To address this need, many organizations have started to use namespaces as units of isolation and tenancy, a pattern previously described by [Google](https://cloud.google.com/kubernetes-engine/docs/concepts/multitenancy-overview) and [Kubernetes contributors](https://kubernetes.io/blog/2021/04/15/three-tenancy-models-for-kubernetes/). But namespace-scoped isolation is often insufficient because some concerns are managed at cluster scope. In particular, installing new resource types (CRDs) is a cluster-scoped activity; and today independent teams often want to install custom resource types and operators. Also, more developers are themselves writing software operators and custom resource types and find themselves requiring cluster-scoped access for research and tests.

## Cluster as unit of tenancy

For these reasons and others, tenants often require their own isolated clusters with unconstrained access rights. In an isolated cluster, a tenant gets its own Kubernetes API server and persistence store and fully manages all namespaces and custom resource types in its cluster.

But deploying physical or even virtual machines for many clusters is inefficient and difficult to manage, so organizations have struggled to provide clusters to tenant teams. Happily :smile:, to meet these organizations' and users' needs, leading Kubernetes vendors have been researching and developing lighter weight mechanisms to provide isolated clusters for an organization's tenants. In this post we'll compare and contrast several of these emergent efforts.

Do you have other projects and ideas to enhance multitenancy for cloud architecture? Then please join CNCF's App Delivery advisory group in discussing these [here](https://github.com/cncf/tag-app-delivery/issues/193); thank you!

### vcluster

[vcluster](https://www.vcluster.com/) is [a prominent project](https://www.google.com/search?q=vcluster&tbm=nws) and CLI tool maintained by [loft.sh](https://loft.sh/) that provisions a virtual cluster as a StatefulSet within a tenant namespace. Access rights from the hosting namespace are propogated to the hosted virtual cluster such that the namespace tenant becomes the cluster's only tenant. As cluster admins, tenant members can create cluster-scoped resources like CRDs and ClusterRoles.

The virtual cluster runs its own Kubernetes API service and persistence store independent of those of the hosting cluster. It can be published by the hosting cluster as a LoadBalancer-type service and accessed directly with kubectl and other Kubernetes API-compliant tools. This enables users of the tenant cluster to work with it directly with little or no knowledge of its host.

In vcluster and the following solutions, the virtual cluster is a "metadata-only" cluster, in that resources in it are persisted to a backing store like etcd, but no schedulers act to reify the persisted resources - ultimately as pods. Instead, a "syncer" synchronization service copies and transforms reifiable resources - podspecs - from the virtual cluster to the hosting namespace of the hosting cluster. Schedulers in the hosting cluster then detect and reify these resources in the same underlying tenant namespace where the virtual cluster's control plane runs.

An advantage of vcluster's approach of scheduling pods in the hosting namespace is that the hosting cluster ultimately handles all workloads and applies namespace quotas - all work happens within the namespace allocated to the tenant by the hosting cluster administrator. A disadvantage is that schedulers cannot be configured in the virtual cluster since pods aren't actually run there.

- [vcluster on GitHub](https://github.com/loft-sh/vcluster)

### Cluster API Provider Nested (CAPN)

In vcluster, bespoke support for control plane implementations is required; as of this writing, vcluster supports k3s, k0s and vanilla k8s distributions.

To support _any_ control plane implementation, the [Cluster API Provider Nested](https://github.com/kubernetes-sigs/cluster-api-provider-nested) project implements an architecture similar to that of vcluster, including a metadata-only cluster and a syncer, but provisions the control plane using a Cluster API provider rather than a bespoke distribution.

CAPN promises to enable control planes implementable via Cluster API to serve virtual clusters.

### HyperShift

Similar to the previous two, [Red Hat](https://www.redhat.com/)'s [HyperShift](https://github.com/openshift/hypershift) project provisions an OpenShift (Red Hat's Kubernetes distro) control plane as a collection of pods in a host namespace. But rather than running workloads within the hosting cluster and namespace like vcluster, HyperShift control planes are connected to a pool of dedicated worker nodes where pods are synced and scheduled.

HyperShift's model may be most appropriate for a hosting provider like Red Hat which desires to abstract control plane management from their customers and allow them to just manage worker nodes.

### kcp

Finally, [kcp](https://github.com/kcp-dev/kcp) is another proposal and project from [Red Hat](https://www.redhat.com/) inspired by and reimagined from all of the previous ideas. Whereas the above virtual clusters run _within_ a host cluster and turn to the host cluster to run pods, manage networks and provision volumes, kcp reverses this paradigm and makes the _hosting_ cluster a metadata-only cluster. _Child_ clusters - _workspaces_ in the kcp project - are registered with the hub metadata-only cluster and work is delegated to these children based on labels on resources in the hub.

As opposed to hosted virtual clusters, child clusters in kcp _could_ manage their own schedulers. Another advantage of kcp's paradigm inversion is centralized awareness and management of child clusters. In particular, this enables simpler centralized policies and standards for custom resource types to be propogated to all children.

## Conclusion

vcluster, CAPN, HyperShift, and kcp are emerging projects and ideas to meet cloud users' needs for multitenancy with _clusters_ as the unit of tenancy. Early adopters are already providing feedback on good and better parts of these approaches and new ideas emerge daily.

Want to help drive new ideas for cloud multitenancy? Want to help cloud users understand and give feedback on emerging paradigms in this domain? Then join [the discussion](https://github.com/cncf/tag-app-delivery/issues/193) in CNCF's TAG App Delivery. Thank you!
Test blog post

0 comments on commit b003ed4

Please sign in to comment.