remove sample config in docs

docs/docs/architecture/attestation.md

@@ -120,7 +120,7 @@ Refer to [images](images.md) for more details on the Constellation boot chain.
 The Constellation [Bootstrapper](components.md#bootstrapper) is the first user mode component that runs in a Constellation image.
 It extends PCR registers with the [IDs](keys.md#cluster-identity) of the cluster marking a node as initialized.
 
-Constellation allows to specify in the [config](../reference/config.md) which measurements should be enforced during the attestation process
+Constellation allows to specify in the config which measurements should be enforced during the attestation process
 Enforcing non-reproducible measurements controlled by the cloud provider means that changes in these values require manual updates to the cluster's config.
 By default, Constellation only enforces measurements that are stable values produced by the infrastructure or by Constellation directly.
 
@@ -187,7 +187,7 @@ The latter means that value can be generated offline and compared to the one in
 
 ## Cluster attestation
 
-Cluster-facing, Constellation's [*JoinService*](components.md#joinservice) verifies each node joining the cluster given the [configured](../reference/config.md) ground truth runtime measurements.
+Cluster-facing, Constellation's [*JoinService*](components.md#joinservice) verifies each node joining the cluster given the configured ground truth runtime measurements.
 User-facing, the [*VerificationService*](components.md#verificationservice) provides an interface to verify a node using remote attestation.
 By verifying the first node during the [initialization](components.md#bootstrapper) and configuring the ground truth measurements that are subsequently enforced by the *JoinService*, the whole cluster is verified in a transitive way.
 

docs/docs/architecture/components.md

@@ -39,7 +39,7 @@ flowchart LR
 
 The *Bootstrapper* is the first component launched after booting a Constellation node image.
 It sets up that machine as a Kubernetes node and integrates that node into the Kubernetes cluster.
-To this end, the *Bootstrapper* first downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the [configured](../reference/config.md) versions.
+To this end, the *Bootstrapper* first downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions.
 The *Bootstrapper* tries to find an existing cluster and if successful, communicates with the [JoinService](components.md#joinservice) to join the node.
 Otherwise, it waits for an initialization request to create a new Kubernetes cluster.
 
@@ -78,4 +78,4 @@ Depending on wether the [constellation-managed](keys.md#constellation-managed-ke
 ## AccessManager
 
 The *AccessManager* runs as DaemonSet on each node.
-It manages the user's SSH access to nodes as specified in the [configuration](../reference/config.md).
+It manages the user's SSH access to nodes as specified in the config.

docs/docs/architecture/images.md

@@ -41,5 +41,5 @@ See the section on [keys and encryption](keys.md#storage-encryption) for more in
 
 ## Kubernetes components
 
-During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as [configured](../reference/config.md) by the user.
+During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as configured by the user.
 They're stored on the state partition and can be updated once new releases need to be installed.

docs/docs/architecture/orchestration.md

@@ -20,7 +20,6 @@ Releases of Constellation are [published on GitHub](https://github.com/edgelesss
 
 To allow for fine-grained configuration of your cluster and cloud environment, Constellation supports an extensive configuration file with strong defaults.
 The CLI provides you with a good default configuration which can be generated with `constellation config generate`. Some cloud account-specific information is always required and to be set by the user.
-Details and examples can be found in the [reference guide](../reference/config.md).
 
 The following files are generated during the creation of a Constellation cluster and stored in the current workspace:
 

docs/docs/reference/config.md

@@ -1,69 +0,0 @@
-# Configuration file
-
-Constellation CLI reads all configuration options from `constellation-conf.yaml`.
-
-> The Constellation CLI can generate a default configuration file. This should be the preferred way, so that the configuration matches the used CLI version.
-
-A sample configuration for a Constellation cluster on Azure looks like this:
-
-```yaml
-version: v1 # Schema version of this configuration file.
-autoscalingNodeGroupMin: 1 # Minimum number of worker nodes in autoscaling group.
-autoscalingNodeGroupMax: 10 # Maximum number of worker nodes in autoscaling group.
-stateDiskSizeGB: 30 # Size (in GB) of a node's disk to store the non-volatile state.
-# Ingress firewall rules for node network.
-ingressFirewall:
-    - name: bootstrapper # Name of rule.
-      description: bootstrapper default port # Description for rule.
-      protocol: tcp # Protocol, such as 'udp' or 'tcp'.
-      iprange: 0.0.0.0/0 # CIDR range for which this rule is applied.
-      fromport: 9000 # Start port of a range.
-      toport: 0 # End port of a range, or 0 if a single port is given by fromport.
-    - name: ssh # Name of rule.
-      description: SSH # Description for rule.
-      protocol: tcp # Protocol, such as 'udp' or 'tcp'.
-      iprange: 0.0.0.0/0 # CIDR range for which this rule is applied.
-      fromport: 22 # Start port of a range.
-      toport: 0 # End port of a range, or 0 if a single port is given by fromport.
-    - name: nodeport # Name of rule.
-      description: NodePort # Description for rule.
-      protocol: tcp # Protocol, such as 'udp' or 'tcp'.
-      iprange: 0.0.0.0/0 # CIDR range for which this rule is applied.
-      fromport: 30000 # Start port of a range.
-      toport: 32767 # End port of a range, or 0 if a single port is given by fromport.
-    - name: kubernetes # Name of rule.
-      description: Kubernetes # Description for rule.
-      protocol: tcp # Protocol, such as 'udp' or 'tcp'.
-      iprange: 0.0.0.0/0 # CIDR range for which this rule is applied.
-      fromport: 6443 # Start port of a range.
-      toport: 0 # End port of a range, or 0 if a single port is given by fromport.
-# Supported cloud providers and their specific configurations.
-provider:
-    # Configuration for Azure as provider.
-    azure:
-        subscription: "" # Subscription ID of the used Azure account. See: https://docs.microsoft.com/en-us/azure/azure-portal/get-subscription-tenant-id#find-your-azure-subscription
-        tenant: "" # Tenant ID of the used Azure account. See: https://docs.microsoft.com/en-us/azure/azure-portal/get-subscription-tenant-id#find-your-azure-ad-tenant
-        location: "" # Azure datacenter region to be used. See: https://docs.microsoft.com/en-us/azure/availability-zones/az-overview#azure-regions-with-availability-zones
-        image: /subscriptions/0d202bbb-4fa7-4af8-8125-58c269a05435/resourceGroups/CONSTELLATION-IMAGES/providers/Microsoft.Compute/galleries/Constellation/images/constellation-coreos/versions/0.0.1659453699 # Machine image used to create Constellation nodes.
-        stateDiskType: StandardSSD_LRS # Type of a node's state disk. The type influences boot time and I/O performance. See: https://docs.microsoft.com/en-us/azure/virtual-machines/disks-types#disk-type-comparison
-        # Expected confidential VM measurements.
-        measurements:
-            11: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
-            12: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
-        userAssignedIdentity: "" # Authorize spawned VMs to access Azure API.
-kubernetesVersion: "1.24" # Kubernetes version installed in the cluster.
-
-# # Egress firewall rules for node network.
-# egressFirewall:
-#     - name: rule#1 # Name of rule.
-#       description: the first rule # Description for rule.
-#       protocol: tcp # Protocol, such as 'udp' or 'tcp'.
-#       iprange: 0.0.0.0/0 # CIDR range for which this rule is applied.
-#       fromport: 443 # Start port of a range.
-#       toport: 443 # End port of a range, or 0 if a single port is given by fromport.
-
-# # Create SSH users on Constellation nodes.
-# sshUsers:
-#     - username: Alice # Username of new SSH user.
-#       publicKey: ssh-rsa AAAAB3NzaC...5QXHKW1rufgtJeSeJ8= alice@domain.com # Public key of new SSH user.
-```

docs/docs/workflows/create.md

@@ -42,7 +42,7 @@ constellation config generate gcp
 </tabItem>
 </tabs>
 
-This creates the file `constellation-conf.yaml` in the current directory. You must edit it before you can execute the next steps. See the [reference section](../reference/config.md) for details.
+This creates the file `constellation-conf.yaml` in the current directory. You must edit it before you can execute the next steps.
 
 Next, download the latest trusted measurements for your configured image.
 

docs/docs/workflows/ssh.md

@@ -2,7 +2,7 @@
 
 Constellation gives you the capability to create UNIX users which can connect to the cluster nodes over SSH, allowing you to access both control-plane and worker nodes. While the nodes' data partitions are persistent, the system partitions are read-only. Consequently, users need to be re-created upon each restart of a node. This is where the Access Manager comes into effect, ensuring the automatic (re-)creation of all users whenever a node is restarted.
 
-During the initial creation of the cluster, all users defined in the `ssh-users` section of the Constellation [configuration file](../reference/config.md) are automatically created during the initialization process. For persistence, the users are stored in a ConfigMap called `ssh-users`, residing in the `kube-system` namespace. For a running cluster, users can be added and removed by modifying the entries of the ConfigMap and performing a restart of a node.
+During the initial creation of the cluster, all users defined in the `ssh-users` section of the Constellation configuration file are automatically created during the initialization process. For persistence, the users are stored in a ConfigMap called `ssh-users`, residing in the `kube-system` namespace. For a running cluster, users can be added and removed by modifying the entries of the ConfigMap and performing a restart of a node.
 
 ## Access Manager
 The Access Manager supports all OpenSSH key types. These are RSA, ECDSA (using the `nistp256`, `nistp384`, `nistp521` curves) and Ed25519. 

docs/sidebars.js

@@ -236,11 +236,6 @@ const sidebars = {
           label: 'CLI',
           id: 'reference/cli',
         },
-        {
-          type: 'doc',
-          label: 'Configuration file',
-          id: 'reference/config',
-        },
       ],
     },
   ],

docs/versioned_docs/version-2.0/architecture/attestation.md

@@ -120,7 +120,7 @@ Refer to [images](images.md) for more details on the Constellation boot chain.
 The Constellation [Bootstrapper](components.md#bootstrapper) is the first user mode component that runs in a Constellation image.
 It extends PCR registers with the [IDs](keys.md#cluster-identity) of the cluster marking a node as initialized.
 
-Constellation allows to specify in the [config](../reference/config.md) which measurements should be enforced during the attestation process
+Constellation allows to specify in the config which measurements should be enforced during the attestation process
 Enforcing non-reproducible measurements controlled by the cloud provider means that changes in these values require manual updates to the cluster's config.
 By default, Constellation only enforces measurements that are stable values produced by the infrastructure or by Constellation directly.
 
@@ -187,7 +187,7 @@ The latter means that value can be generated offline and compared to the one in
 
 ## Cluster attestation
 
-Cluster-facing, Constellation's [*JoinService*](components.md#joinservice) verifies each node joining the cluster given the [configured](../reference/config.md) ground truth runtime measurements.
+Cluster-facing, Constellation's [*JoinService*](components.md#joinservice) verifies each node joining the cluster given the configured ground truth runtime measurements.
 User-facing, the [*VerificationService*](components.md#verificationservice) provides an interface to verify a node using remote attestation.
 By verifying the first node during the [initialization](components.md#bootstrapper) and configuring the ground truth measurements that are subsequently enforced by the *JoinService*, the whole cluster is verified in a transitive way.
 

docs/versioned_docs/version-2.0/architecture/components.md

@@ -39,7 +39,7 @@ flowchart LR
 
 The *Bootstrapper* is the first component launched after booting a Constellation node image.
 It sets up that machine as a Kubernetes node and integrates that node into the Kubernetes cluster.
-To this end, the *Bootstrapper* first downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the [configured](../reference/config.md) versions.
+To this end, the *Bootstrapper* first downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions.
 The *Bootstrapper* tries to find an existing cluster and if successful, communicates with the [JoinService](components.md#joinservice) to join the node.
 Otherwise, it waits for an initialization request to create a new Kubernetes cluster.
 
@@ -78,4 +78,4 @@ Depending on wether the [constellation-managed](keys.md#constellation-managed-ke
 ## AccessManager
 
 The *AccessManager* runs as DaemonSet on each node.
-It manages the user's SSH access to nodes as specified in the [configuration](../reference/config.md).
+It manages the user's SSH access to nodes as specified in the config.

docs/versioned_docs/version-2.0/architecture/images.md

@@ -41,5 +41,5 @@ See the section on [keys and encryption](keys.md#storage-encryption) for more in
 
 ## Kubernetes components
 
-During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as [configured](../reference/config.md) by the user.
+During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as configured by the user.
 They're stored on the state partition and can be updated once new releases need to be installed.

docs/versioned_docs/version-2.0/architecture/orchestration.md

@@ -20,7 +20,6 @@ Releases of Constellation are [published on GitHub](https://github.com/edgelesss
 
 To allow for fine-grained configuration of your cluster and cloud environment, Constellation supports an extensive configuration file with strong defaults.
 The CLI provides you with a good default configuration which can be generated with `constellation config generate`. Some cloud account-specific information is always required and to be set by the user.
-Details and examples can be found in the [reference guide](../reference/config.md).
 
 The following files are generated during the creation of a Constellation cluster and stored in the current workspace:
 

docs/versioned_docs/version-2.0/reference/config.md

@@ -1,69 +0,0 @@
-# Configuration file
-
-Constellation CLI reads all configuration options from `constellation-conf.yaml`.
-
-> The Constellation CLI can generate a default configuration file. This should be the preferred way, so that the configuration matches the used CLI version.
-
-A sample configuration for a Constellation cluster on Azure looks like this:
-
-```yaml
-version: v1 # Schema version of this configuration file.
-autoscalingNodeGroupMin: 1 # Minimum number of worker nodes in autoscaling group.
-autoscalingNodeGroupMax: 10 # Maximum number of worker nodes in autoscaling group.
-stateDiskSizeGB: 30 # Size (in GB) of a node's disk to store the non-volatile state.
-# Ingress firewall rules for node network.
-ingressFirewall:
-    - name: bootstrapper # Name of rule.
-      description: bootstrapper default port # Description for rule.
-      protocol: tcp # Protocol, such as 'udp' or 'tcp'.
-      iprange: 0.0.0.0/0 # CIDR range for which this rule is applied.
-      fromport: 9000 # Start port of a range.
-      toport: 0 # End port of a range, or 0 if a single port is given by fromport.
-    - name: ssh # Name of rule.
-      description: SSH # Description for rule.
-      protocol: tcp # Protocol, such as 'udp' or 'tcp'.
-      iprange: 0.0.0.0/0 # CIDR range for which this rule is applied.
-      fromport: 22 # Start port of a range.
-      toport: 0 # End port of a range, or 0 if a single port is given by fromport.
-    - name: nodeport # Name of rule.
-      description: NodePort # Description for rule.
-      protocol: tcp # Protocol, such as 'udp' or 'tcp'.
-      iprange: 0.0.0.0/0 # CIDR range for which this rule is applied.
-      fromport: 30000 # Start port of a range.
-      toport: 32767 # End port of a range, or 0 if a single port is given by fromport.
-    - name: kubernetes # Name of rule.
-      description: Kubernetes # Description for rule.
-      protocol: tcp # Protocol, such as 'udp' or 'tcp'.
-      iprange: 0.0.0.0/0 # CIDR range for which this rule is applied.
-      fromport: 6443 # Start port of a range.
-      toport: 0 # End port of a range, or 0 if a single port is given by fromport.
-# Supported cloud providers and their specific configurations.
-provider:
-    # Configuration for Azure as provider.
-    azure:
-        subscription: "" # Subscription ID of the used Azure account. See: https://docs.microsoft.com/en-us/azure/azure-portal/get-subscription-tenant-id#find-your-azure-subscription
-        tenant: "" # Tenant ID of the used Azure account. See: https://docs.microsoft.com/en-us/azure/azure-portal/get-subscription-tenant-id#find-your-azure-ad-tenant
-        location: "" # Azure datacenter region to be used. See: https://docs.microsoft.com/en-us/azure/availability-zones/az-overview#azure-regions-with-availability-zones
-        image: /subscriptions/0d202bbb-4fa7-4af8-8125-58c269a05435/resourceGroups/CONSTELLATION-IMAGES/providers/Microsoft.Compute/galleries/Constellation/images/constellation-coreos/versions/0.0.1659453699 # Machine image used to create Constellation nodes.
-        stateDiskType: StandardSSD_LRS # Type of a node's state disk. The type influences boot time and I/O performance. See: https://docs.microsoft.com/en-us/azure/virtual-machines/disks-types#disk-type-comparison
-        # Expected confidential VM measurements.
-        measurements:
-            11: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
-            12: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
-        userAssignedIdentity: "" # Authorize spawned VMs to access Azure API.
-kubernetesVersion: "1.24" # Kubernetes version installed in the cluster.
-
-# # Egress firewall rules for node network.
-# egressFirewall:
-#     - name: rule#1 # Name of rule.
-#       description: the first rule # Description for rule.
-#       protocol: tcp # Protocol, such as 'udp' or 'tcp'.
-#       iprange: 0.0.0.0/0 # CIDR range for which this rule is applied.
-#       fromport: 443 # Start port of a range.
-#       toport: 443 # End port of a range, or 0 if a single port is given by fromport.
-
-# # Create SSH users on Constellation nodes.
-# sshUsers:
-#     - username: Alice # Username of new SSH user.
-#       publicKey: ssh-rsa AAAAB3NzaC...5QXHKW1rufgtJeSeJ8= alice@domain.com # Public key of new SSH user.
-```

docs/versioned_docs/version-2.0/workflows/create.md

@@ -42,7 +42,7 @@ constellation config generate gcp
 </tabItem>
 </tabs>
 
-This creates the file `constellation-conf.yaml` in the current directory. You must edit it before you can execute the next steps. See the [reference section](../reference/config.md) for details.
+This creates the file `constellation-conf.yaml` in the current directory. You must edit it before you can execute the next steps.
 
 Next, download the latest trusted measurements for your configured image.
 

docs/versioned_docs/version-2.0/workflows/ssh.md

@@ -2,7 +2,7 @@
 
 Constellation gives you the capability to create UNIX users which can connect to the cluster nodes over SSH, allowing you to access both control-plane and worker nodes. While the nodes' data partitions are persistent, the system partitions are read-only. Consequently, users need to be re-created upon each restart of a node. This is where the Access Manager comes into effect, ensuring the automatic (re-)creation of all users whenever a node is restarted.
 
-During the initial creation of the cluster, all users defined in the `ssh-users` section of the Constellation [configuration file](../reference/config.md) are automatically created during the initialization process. For persistence, the users are stored in a ConfigMap called `ssh-users`, residing in the `kube-system` namespace. For a running cluster, users can be added and removed by modifying the entries of the ConfigMap and performing a restart of a node.
+During the initial creation of the cluster, all users defined in the `ssh-users` section of the Constellation configuration file are automatically created during the initialization process. For persistence, the users are stored in a ConfigMap called `ssh-users`, residing in the `kube-system` namespace. For a running cluster, users can be added and removed by modifying the entries of the ConfigMap and performing a restart of a node.
 
 ## Access Manager
 The Access Manager supports all OpenSSH key types. These are RSA, ECDSA (using the `nistp256`, `nistp384`, `nistp521` curves) and Ed25519. 

docs/versioned_sidebars/version-2.0-sidebars.json

@@ -217,11 +217,6 @@
           "type": "doc",
           "label": "CLI",
           "id": "reference/cli"
-        },
-        {
-          "type": "doc",
-          "label": "Configuration file",
-          "id": "reference/config"
         }
       ]
     }