diff --git a/.gitignore b/.gitignore index 5f1fd39727..59e94cf386 100644 --- a/.gitignore +++ b/.gitignore @@ -125,4 +125,4 @@ package.json package-lock.json # class generator script -script/resource/debug/*-debug.json +script/resource/debug/* diff --git a/scripts/resource/debug/APIServer-debug.json b/scripts/resource/debug/APIServer-debug.json deleted file mode 100644 index 3a2819a133..0000000000 --- a/scripts/resource/debug/APIServer-debug.json +++ /dev/null @@ -1,10 +0,0 @@ -{ - "explain": "GROUP: config.openshift.io\nKIND: APIServer\nVERSION: v1\n\nDESCRIPTION:\n APIServer holds configuration (like serving certificates, client CA and CORS\n domains) shared by all API servers in the system, among them especially\n kube-apiserver and openshift-apiserver. The canonical name of an instance is\n 'cluster'. \n Compatibility level 1: Stable within a major release for a minimum of 12\n months or 3 minor releases (whichever is longer).\n \nFIELDS:\n apiVersion\t\n kind\t\n metadata\t\n annotations\t\n creationTimestamp\t\n deletionGracePeriodSeconds\t\n deletionTimestamp\t\n finalizers\t<[]string>\n generateName\t\n generation\t\n labels\t\n managedFields\t<[]ManagedFieldsEntry>\n apiVersion\t\n fieldsType\t\n fieldsV1\t\n manager\t\n operation\t\n subresource\t\n time\t\n name\t\n namespace\t\n ownerReferences\t<[]OwnerReference>\n apiVersion\t -required-\n blockOwnerDeletion\t\n controller\t\n kind\t -required-\n name\t -required-\n uid\t -required-\n resourceVersion\t\n selfLink\t\n uid\t\n spec\t -required-\n additionalCORSAllowedOrigins\t<[]string>\n audit\t\n customRules\t<[]Object>\n group\t -required-\n profile\t -required-\n profile\t\n clientCA\t\n name\t -required-\n encryption\t\n type\t\n servingCerts\t\n namedCertificates\t<[]Object>\n names\t<[]string>\n servingCertificate\t\n name\t -required-\n tlsSecurityProfile\t\n custom\t\n ciphers\t<[]string>\n minTLSVersion\t\n intermediate\t\n modern\t\n old\t\n type\t\n status\t\n\n", - "namespace": "0\n", - "explain-additionalCORSAllowedOrigins": "GROUP: config.openshift.io\nKIND: APIServer\nVERSION: v1\n\nFIELD: additionalCORSAllowedOrigins <[]string>\n\nDESCRIPTION:\n additionalCORSAllowedOrigins lists additional, user-defined regular\n expressions describing hosts for which the API server allows access using\n the CORS headers. This may be needed to access the API and the integrated\n OAuth server from JavaScript applications. The values are regular\n expressions that correspond to the Golang regular expression language.\n \n\n", - "explain-audit": "GROUP: config.openshift.io\nKIND: APIServer\nVERSION: v1\n\nFIELD: audit \n\nDESCRIPTION:\n audit specifies the settings for audit configuration to be applied to all\n OpenShift-provided API servers in the cluster.\n \nFIELDS:\n customRules\t<[]Object>\n customRules specify profiles per group. These profile take precedence over\n the top-level profile field if they apply. They are evaluation from top to\n bottom and the first one that matches, applies.\n\n profile\t\n profile specifies the name of the desired top-level audit profile to be\n applied to all requests sent to any of the OpenShift-provided API servers in\n the cluster (kube-apiserver, openshift-apiserver and oauth-apiserver), with\n the exception of those requests that match one or more of the customRules. \n The following profiles are provided: - Default: default policy which means\n MetaData level logging with the exception of events (not logged at all),\n oauthaccesstokens and oauthauthorizetokens (both logged at RequestBody\n level). - WriteRequestBodies: like 'Default', but logs request and response\n HTTP payloads for write requests (create, update, patch). -\n AllRequestBodies: like 'WriteRequestBodies', but also logs request and\n response HTTP payloads for read requests (get, list). - None: no requests\n are logged at all, not even oauthaccesstokens and oauthauthorizetokens. \n Warning: It is not recommended to disable audit logging by using the `None`\n profile unless you are fully aware of the risks of not logging data that can\n be beneficial when troubleshooting issues. If you disable audit logging and\n a support situation arises, you might need to enable audit logging and\n reproduce the issue in order to troubleshoot properly. \n If unset, the 'Default' profile is used as the default.\n\n\n", - "explain-clientCA": "GROUP: config.openshift.io\nKIND: APIServer\nVERSION: v1\n\nFIELD: clientCA \n\nDESCRIPTION:\n clientCA references a ConfigMap containing a certificate bundle for the\n signers that will be recognized for incoming client certificates in addition\n to the operator managed signers. If this is empty, then only operator\n managed signers are valid. You usually only have to set this if you have\n your own PKI you wish to honor client certificates from. The ConfigMap must\n exist in the openshift-config namespace and contain the following required\n fields: - ConfigMap.Data[\"ca-bundle.crt\"] - CA bundle.\n \nFIELDS:\n name\t -required-\n name is the metadata.name of the referenced config map\n\n\n", - "explain-encryption": "GROUP: config.openshift.io\nKIND: APIServer\nVERSION: v1\n\nFIELD: encryption \n\nDESCRIPTION:\n encryption allows the configuration of encryption of resources at the\n datastore layer.\n \nFIELDS:\n type\t\n type defines what encryption type should be used to encrypt resources at the\n datastore layer. When this field is unset (i.e. when it is set to the empty\n string), identity is implied. The behavior of unset can and will change over\n time. Even if encryption is enabled by default, the meaning of unset may\n change to a different encryption type based on changes in best practices. \n When encryption is enabled, all sensitive resources shipped with the\n platform are encrypted. This list of sensitive resources can and will change\n over time. The current authoritative list is: \n 1. secrets 2. configmaps 3. routes.route.openshift.io 4.\n oauthaccesstokens.oauth.openshift.io 5.\n oauthauthorizetokens.oauth.openshift.io\n\n\n", - "explain-servingCerts": "GROUP: config.openshift.io\nKIND: APIServer\nVERSION: v1\n\nFIELD: servingCerts \n\nDESCRIPTION:\n servingCert is the TLS cert info for serving secure traffic. If not\n specified, operator managed certificates will be used for serving secure\n traffic.\n \nFIELDS:\n namedCertificates\t<[]Object>\n namedCertificates references secrets containing the TLS cert info for\n serving secure traffic to specific hostnames. If no named certificates are\n provided, or no named certificates match the server name as understood by a\n client, the defaultServingCertificate will be used.\n\n\n", - "explain-tlsSecurityProfile": "GROUP: config.openshift.io\nKIND: APIServer\nVERSION: v1\n\nFIELD: tlsSecurityProfile \n\nDESCRIPTION:\n tlsSecurityProfile specifies settings for TLS connections for externally\n exposed servers. \n If unset, a default (which may change between releases) is chosen. Note\n that only Old, Intermediate and Custom profiles are currently supported, and\n the maximum available minTLSVersion is VersionTLS12.\n \nFIELDS:\n custom\t\n custom is a user-defined TLS security profile. Be extremely careful using a\n custom profile as invalid configurations can be catastrophic. An example\n custom profile looks like this: \n ciphers: \n - ECDHE-ECDSA-CHACHA20-POLY1305 \n - ECDHE-RSA-CHACHA20-POLY1305 \n - ECDHE-RSA-AES128-GCM-SHA256 \n - ECDHE-ECDSA-AES128-GCM-SHA256 \n minTLSVersion: VersionTLS11\n\n intermediate\t\n intermediate is a TLS security profile based on: \n https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28recommended.29\n and looks like this (yaml): \n ciphers: \n - TLS_AES_128_GCM_SHA256 \n - TLS_AES_256_GCM_SHA384 \n - TLS_CHACHA20_POLY1305_SHA256 \n - ECDHE-ECDSA-AES128-GCM-SHA256 \n - ECDHE-RSA-AES128-GCM-SHA256 \n - ECDHE-ECDSA-AES256-GCM-SHA384 \n - ECDHE-RSA-AES256-GCM-SHA384 \n - ECDHE-ECDSA-CHACHA20-POLY1305 \n - ECDHE-RSA-CHACHA20-POLY1305 \n - DHE-RSA-AES128-GCM-SHA256 \n - DHE-RSA-AES256-GCM-SHA384 \n minTLSVersion: VersionTLS12\n\n modern\t\n modern is a TLS security profile based on: \n https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility \n and looks like this (yaml): \n ciphers: \n - TLS_AES_128_GCM_SHA256 \n - TLS_AES_256_GCM_SHA384 \n - TLS_CHACHA20_POLY1305_SHA256 \n minTLSVersion: VersionTLS13\n\n old\t\n old is a TLS security profile based on: \n https://wiki.mozilla.org/Security/Server_Side_TLS#Old_backward_compatibility\n and looks like this (yaml): \n ciphers: \n - TLS_AES_128_GCM_SHA256 \n - TLS_AES_256_GCM_SHA384 \n - TLS_CHACHA20_POLY1305_SHA256 \n - ECDHE-ECDSA-AES128-GCM-SHA256 \n - ECDHE-RSA-AES128-GCM-SHA256 \n - ECDHE-ECDSA-AES256-GCM-SHA384 \n - ECDHE-RSA-AES256-GCM-SHA384 \n - ECDHE-ECDSA-CHACHA20-POLY1305 \n - ECDHE-RSA-CHACHA20-POLY1305 \n - DHE-RSA-AES128-GCM-SHA256 \n - DHE-RSA-AES256-GCM-SHA384 \n - DHE-RSA-CHACHA20-POLY1305 \n - ECDHE-ECDSA-AES128-SHA256 \n - ECDHE-RSA-AES128-SHA256 \n - ECDHE-ECDSA-AES128-SHA \n - ECDHE-RSA-AES128-SHA \n - ECDHE-ECDSA-AES256-SHA384 \n - ECDHE-RSA-AES256-SHA384 \n - ECDHE-ECDSA-AES256-SHA \n - ECDHE-RSA-AES256-SHA \n - DHE-RSA-AES128-SHA256 \n - DHE-RSA-AES256-SHA256 \n - AES128-GCM-SHA256 \n - AES256-GCM-SHA384 \n - AES128-SHA256 \n - AES256-SHA256 \n - AES128-SHA \n - AES256-SHA \n - DES-CBC3-SHA \n minTLSVersion: VersionTLS10\n\n type\t\n type is one of Old, Intermediate, Modern or Custom. Custom provides the\n ability to specify individual TLS security profile parameters. Old,\n Intermediate and Modern are TLS security profiles based on: \n https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations\n The profiles are intent based, so they may change over time as new ciphers\n are developed and existing ciphers are found to be insecure. Depending on\n precisely which ciphers are available to a process, the list may be reduced.\n Note that the Modern profile is currently not supported because it is not\n yet well adopted by common software libraries.\n\n\n" -} diff --git a/scripts/resource/debug/apis_erver_debug.json b/scripts/resource/debug/apis_erver_debug.json deleted file mode 100644 index 3a2819a133..0000000000 --- a/scripts/resource/debug/apis_erver_debug.json +++ /dev/null @@ -1,10 +0,0 @@ -{ - "explain": "GROUP: config.openshift.io\nKIND: APIServer\nVERSION: v1\n\nDESCRIPTION:\n APIServer holds configuration (like serving certificates, client CA and CORS\n domains) shared by all API servers in the system, among them especially\n kube-apiserver and openshift-apiserver. The canonical name of an instance is\n 'cluster'. \n Compatibility level 1: Stable within a major release for a minimum of 12\n months or 3 minor releases (whichever is longer).\n \nFIELDS:\n apiVersion\t\n kind\t\n metadata\t\n annotations\t\n creationTimestamp\t\n deletionGracePeriodSeconds\t\n deletionTimestamp\t\n finalizers\t<[]string>\n generateName\t\n generation\t\n labels\t\n managedFields\t<[]ManagedFieldsEntry>\n apiVersion\t\n fieldsType\t\n fieldsV1\t\n manager\t\n operation\t\n subresource\t\n time\t\n name\t\n namespace\t\n ownerReferences\t<[]OwnerReference>\n apiVersion\t -required-\n blockOwnerDeletion\t\n controller\t\n kind\t -required-\n name\t -required-\n uid\t -required-\n resourceVersion\t\n selfLink\t\n uid\t\n spec\t -required-\n additionalCORSAllowedOrigins\t<[]string>\n audit\t\n customRules\t<[]Object>\n group\t -required-\n profile\t -required-\n profile\t\n clientCA\t\n name\t -required-\n encryption\t\n type\t\n servingCerts\t\n namedCertificates\t<[]Object>\n names\t<[]string>\n servingCertificate\t\n name\t -required-\n tlsSecurityProfile\t\n custom\t\n ciphers\t<[]string>\n minTLSVersion\t\n intermediate\t\n modern\t\n old\t\n type\t\n status\t\n\n", - "namespace": "0\n", - "explain-additionalCORSAllowedOrigins": "GROUP: config.openshift.io\nKIND: APIServer\nVERSION: v1\n\nFIELD: additionalCORSAllowedOrigins <[]string>\n\nDESCRIPTION:\n additionalCORSAllowedOrigins lists additional, user-defined regular\n expressions describing hosts for which the API server allows access using\n the CORS headers. This may be needed to access the API and the integrated\n OAuth server from JavaScript applications. The values are regular\n expressions that correspond to the Golang regular expression language.\n \n\n", - "explain-audit": "GROUP: config.openshift.io\nKIND: APIServer\nVERSION: v1\n\nFIELD: audit \n\nDESCRIPTION:\n audit specifies the settings for audit configuration to be applied to all\n OpenShift-provided API servers in the cluster.\n \nFIELDS:\n customRules\t<[]Object>\n customRules specify profiles per group. These profile take precedence over\n the top-level profile field if they apply. They are evaluation from top to\n bottom and the first one that matches, applies.\n\n profile\t\n profile specifies the name of the desired top-level audit profile to be\n applied to all requests sent to any of the OpenShift-provided API servers in\n the cluster (kube-apiserver, openshift-apiserver and oauth-apiserver), with\n the exception of those requests that match one or more of the customRules. \n The following profiles are provided: - Default: default policy which means\n MetaData level logging with the exception of events (not logged at all),\n oauthaccesstokens and oauthauthorizetokens (both logged at RequestBody\n level). - WriteRequestBodies: like 'Default', but logs request and response\n HTTP payloads for write requests (create, update, patch). -\n AllRequestBodies: like 'WriteRequestBodies', but also logs request and\n response HTTP payloads for read requests (get, list). - None: no requests\n are logged at all, not even oauthaccesstokens and oauthauthorizetokens. \n Warning: It is not recommended to disable audit logging by using the `None`\n profile unless you are fully aware of the risks of not logging data that can\n be beneficial when troubleshooting issues. If you disable audit logging and\n a support situation arises, you might need to enable audit logging and\n reproduce the issue in order to troubleshoot properly. \n If unset, the 'Default' profile is used as the default.\n\n\n", - "explain-clientCA": "GROUP: config.openshift.io\nKIND: APIServer\nVERSION: v1\n\nFIELD: clientCA \n\nDESCRIPTION:\n clientCA references a ConfigMap containing a certificate bundle for the\n signers that will be recognized for incoming client certificates in addition\n to the operator managed signers. If this is empty, then only operator\n managed signers are valid. You usually only have to set this if you have\n your own PKI you wish to honor client certificates from. The ConfigMap must\n exist in the openshift-config namespace and contain the following required\n fields: - ConfigMap.Data[\"ca-bundle.crt\"] - CA bundle.\n \nFIELDS:\n name\t -required-\n name is the metadata.name of the referenced config map\n\n\n", - "explain-encryption": "GROUP: config.openshift.io\nKIND: APIServer\nVERSION: v1\n\nFIELD: encryption \n\nDESCRIPTION:\n encryption allows the configuration of encryption of resources at the\n datastore layer.\n \nFIELDS:\n type\t\n type defines what encryption type should be used to encrypt resources at the\n datastore layer. When this field is unset (i.e. when it is set to the empty\n string), identity is implied. The behavior of unset can and will change over\n time. Even if encryption is enabled by default, the meaning of unset may\n change to a different encryption type based on changes in best practices. \n When encryption is enabled, all sensitive resources shipped with the\n platform are encrypted. This list of sensitive resources can and will change\n over time. The current authoritative list is: \n 1. secrets 2. configmaps 3. routes.route.openshift.io 4.\n oauthaccesstokens.oauth.openshift.io 5.\n oauthauthorizetokens.oauth.openshift.io\n\n\n", - "explain-servingCerts": "GROUP: config.openshift.io\nKIND: APIServer\nVERSION: v1\n\nFIELD: servingCerts \n\nDESCRIPTION:\n servingCert is the TLS cert info for serving secure traffic. If not\n specified, operator managed certificates will be used for serving secure\n traffic.\n \nFIELDS:\n namedCertificates\t<[]Object>\n namedCertificates references secrets containing the TLS cert info for\n serving secure traffic to specific hostnames. If no named certificates are\n provided, or no named certificates match the server name as understood by a\n client, the defaultServingCertificate will be used.\n\n\n", - "explain-tlsSecurityProfile": "GROUP: config.openshift.io\nKIND: APIServer\nVERSION: v1\n\nFIELD: tlsSecurityProfile \n\nDESCRIPTION:\n tlsSecurityProfile specifies settings for TLS connections for externally\n exposed servers. \n If unset, a default (which may change between releases) is chosen. Note\n that only Old, Intermediate and Custom profiles are currently supported, and\n the maximum available minTLSVersion is VersionTLS12.\n \nFIELDS:\n custom\t\n custom is a user-defined TLS security profile. Be extremely careful using a\n custom profile as invalid configurations can be catastrophic. An example\n custom profile looks like this: \n ciphers: \n - ECDHE-ECDSA-CHACHA20-POLY1305 \n - ECDHE-RSA-CHACHA20-POLY1305 \n - ECDHE-RSA-AES128-GCM-SHA256 \n - ECDHE-ECDSA-AES128-GCM-SHA256 \n minTLSVersion: VersionTLS11\n\n intermediate\t\n intermediate is a TLS security profile based on: \n https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28recommended.29\n and looks like this (yaml): \n ciphers: \n - TLS_AES_128_GCM_SHA256 \n - TLS_AES_256_GCM_SHA384 \n - TLS_CHACHA20_POLY1305_SHA256 \n - ECDHE-ECDSA-AES128-GCM-SHA256 \n - ECDHE-RSA-AES128-GCM-SHA256 \n - ECDHE-ECDSA-AES256-GCM-SHA384 \n - ECDHE-RSA-AES256-GCM-SHA384 \n - ECDHE-ECDSA-CHACHA20-POLY1305 \n - ECDHE-RSA-CHACHA20-POLY1305 \n - DHE-RSA-AES128-GCM-SHA256 \n - DHE-RSA-AES256-GCM-SHA384 \n minTLSVersion: VersionTLS12\n\n modern\t\n modern is a TLS security profile based on: \n https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility \n and looks like this (yaml): \n ciphers: \n - TLS_AES_128_GCM_SHA256 \n - TLS_AES_256_GCM_SHA384 \n - TLS_CHACHA20_POLY1305_SHA256 \n minTLSVersion: VersionTLS13\n\n old\t\n old is a TLS security profile based on: \n https://wiki.mozilla.org/Security/Server_Side_TLS#Old_backward_compatibility\n and looks like this (yaml): \n ciphers: \n - TLS_AES_128_GCM_SHA256 \n - TLS_AES_256_GCM_SHA384 \n - TLS_CHACHA20_POLY1305_SHA256 \n - ECDHE-ECDSA-AES128-GCM-SHA256 \n - ECDHE-RSA-AES128-GCM-SHA256 \n - ECDHE-ECDSA-AES256-GCM-SHA384 \n - ECDHE-RSA-AES256-GCM-SHA384 \n - ECDHE-ECDSA-CHACHA20-POLY1305 \n - ECDHE-RSA-CHACHA20-POLY1305 \n - DHE-RSA-AES128-GCM-SHA256 \n - DHE-RSA-AES256-GCM-SHA384 \n - DHE-RSA-CHACHA20-POLY1305 \n - ECDHE-ECDSA-AES128-SHA256 \n - ECDHE-RSA-AES128-SHA256 \n - ECDHE-ECDSA-AES128-SHA \n - ECDHE-RSA-AES128-SHA \n - ECDHE-ECDSA-AES256-SHA384 \n - ECDHE-RSA-AES256-SHA384 \n - ECDHE-ECDSA-AES256-SHA \n - ECDHE-RSA-AES256-SHA \n - DHE-RSA-AES128-SHA256 \n - DHE-RSA-AES256-SHA256 \n - AES128-GCM-SHA256 \n - AES256-GCM-SHA384 \n - AES128-SHA256 \n - AES256-SHA256 \n - AES128-SHA \n - AES256-SHA \n - DES-CBC3-SHA \n minTLSVersion: VersionTLS10\n\n type\t\n type is one of Old, Intermediate, Modern or Custom. Custom provides the\n ability to specify individual TLS security profile parameters. Old,\n Intermediate and Modern are TLS security profiles based on: \n https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations\n The profiles are intent based, so they may change over time as new ciphers\n are developed and existing ciphers are found to be insecure. Depending on\n precisely which ciphers are available to a process, the list may be reduced.\n Note that the Modern profile is currently not supported because it is not\n yet well adopted by common software libraries.\n\n\n" -}