* azure: validate cluster name against Azure reserved words
Azure prohibits the use of certain reserved words and trademarks
in resource names. This change adds validation to reject cluster
names containing any of the 43 reserved words documented by Azure,
preventing deployment failures with ReservedResourceName errors.
Reserved words checked include:
- Complete reserved words (40): AZURE, OFFICE, EXCHANGE, etc.
- Substring forbidden (2): MICROSOFT, WINDOWS
- Prefix forbidden (1): LOGIN
* update the checking logic on reserved words
* fix the gofmt issues
Instead of trying to infer the installation method from an unreliable
parsing of the command line arguments, pass a flag to explicitly
identify the agent-based install method.
On Prem clusters with a dot in the cluster name causes issues
in keepalived and should be validated to prevent this. Adding
an extra check to make sure there are no dots in the cluster
name.
The vsphere vcenter validation in the installer right now is
to check if the first character starts with a lowercase alphabet
but we should allow digits as well so removing the first
character check in validation.
GCP does not allow certain resources to have names with words
similar to 'google'. Adding a regex check for known invalid
cluster names in GCP to inform the user before trying to create
the cluster.
Tested values:
Passed: test-googl, testgoogl-test, testgoogl, goo-test
Failed: goog-test, test-google, testgoogletest
Vcenter input must always only be the hostname yet it is possible
for the user to provide other types of input like URLs. URLs would
cause an error to occur only during the time of cluster creation
as connection to the vcenter would succeed.
Adding a validation check for the user input for the vcenter value
so that it conforms to the RFC-1035 standard and forces the user
to re-enter the value rather than throw an error during cluster
creation.
When users specify a custom MAC address for the provisioning and
baremetal bridges of the libvirt bootstrap host, libvirt complains
if the user does not give a unicast MAC address:
```
020-11-13 10:52:18 level=debug msg=2020/11/13 10:52:18 [ERROR]
module.bootstrap: eval: *terraform.EvalApplyPost, err: Error defining
libvirt domain: virError(Code=27, Domain=20, Message='XML error:
expected unicast mac address, found multicast '7D:CE:E3:29:35:6F'')
')
```
This adds a function that validates whether a MAC address is unicast. A
multicast MAC address is one where the most significant byte has a least
significant bit of `1`.
Example 1: Multicast MAC
------------------------
7D:CE:E3:29:35:6F
^--> most significant byte
0x7D is 0b11111101
^--> this is a multicast MAC
Example 2: Unicast MAC
----------------------
7A:CE:E3:29:35:6F
^--> most significant byte
0x7A is 0b11111010
^--> this is a unicast MAC
Additionally, the built-in ParseMAC in go net accepts EUI-64 and
Infiniband macs. This updates our validator to make sure we have
EUI-48 (6-octet) MAC address as well.
The networking team has made an argument that not allowing docker default network bridge for machine, service and cluster networks is
an invalid validation see https://bugzilla.redhat.com/show_bug.cgi?id=1858342#c2 . So we are dropping that validation.
But on libvirt platform overlap with docker bridge has known to cause problems therefore we are keeping the validation for this platform.
Also when this network range is in use, warning is shown to the user so that in case users keep weird errors we can quickly traige to networking team.
Prior to this change, GCP and Azure did not allow periods in the cluster
names because that would violate their API naming conventions. However,
newer versions of the installer create cloud assets based on the InfraID,
where all periods are now translated to dashes.
This change modifies the verification to allow periods. As a result,
users can now create clusters with names such as "my.prod". They must
otherwise comply with RFC1035 "[a-z]([-a-z0-9]*[a-z0-9])?".
Add validation that checks the networking section of install-config.yaml
for consistent with regards to IPv6 and dual-stack support.
Rules:
* If any networking list (service, pod, or machine) has IPv6 and IPv4
CIDRs, all fields must have both sets of addresses
* Except on AWS, which allows the machine field to only have a single IPv4 CIDR
* Only BareMetal and None can provide dual-stack or ipv6 addresses
* Will be changed by forthcoming PRs that add support for AWS and Azure
* Other platforms may have a toleration mode for UPI that will be relaxed in 4.4
* Block OpenShiftSDN when IPv6 is requested since it is not implemented
* ServiceNetwork must always have 1 or 2 entries, for single or dual stack
These rules may be altered by subsequent changes if we need to relax requirements.
A helper method is provided to determine which mode is requested for a given
install-config which should be used during asset generation per platform.
Relax validation on SubnetCIDR and move logic to this new function.
The current validation assumes that interfaces exist on the same host as
running the installer, although we expose the ability to change the
libvirtURI. This means the bootstrap VM could theoretically be placed
on a remote host, so we should validate the interfaces through libvirt
to handle that case.
Because the platform validators always get compiled, we add a new
mechanism for registering dynamic validators that are only used when the
baremetal platform has been compiled into the openshift-install.
Upon failure to connect to libvirt at all, the user will get a message
like:
```
FATAL failed to fetch Terraform Variables: failed to load asset "Install
Config": invalid "install-config.yaml" file:
platform.baremetal.libvirtURI: Internal error: could not connect to
libvirt: virError(Code=38, Domain=7, Message='Failed to connect socket
to '/var/run/libvirt/libvirt-sock': Connection refused')
```
If an interface name is invalid, you'll receive a message like:
````
FATAL failed to fetch Terraform Variables: failed to load asset "Install
Config": invalid "install-config.yaml" file:
platform.baremetal.provisioningBridge: Invalid value: "potato": could
not find interface "potato", valid interfaces are baremetal, eno1, eno2,
lo, provisioning
````
Save a few characters and get safer quoting if the user gives us a
candidate IP address that contains a single quote or some such.
The error messages I'm touching in the unit tests are fairly
redundant, but I didn't drop their inclusion of the validate.IP error
in case we make the error messages more specific later.
To support MITM (ssl) proxy and registries add an optional
AdditionalTrustBundle string to InstallConfig.
Modified InstallConfig to include AdditionalTrustBundle
Add validation of certificate that is provided via InstallConfig
Modify BootstrapTemplateData to include AdditionalTrustBundle
Add a template for ca.crt in /etc/pki/ca-trust/source/anchors
Add update-trust.sh script to update-ca-trust if ca.crt file exists in /etc/pki/ca-trust/source/anchors
Add machineconfig ForAdditionalTrustBundle function
Modified master and worker asset machines for AdditionalTrustBundle
Add Tests for validate AdditionalTrustBundle
Add additionaltrustbundleconfig that creates a ConfigMap
that contains the Proxy CA files.
This adds experimental support for the baremetal IPI platform. Baremetal
IPI is implemented via a libvirt bootstrap VM, and an Ironic instance
that handles provisioning of baremetal nodes.
This baremetal platform is still experimental and relies on the
openshift-metal3/dev-scripts to perform a complete deployment.
Co-authored-by: Antoni Segura Puimedon <antoni@redhat.com>
Co-authored-by: Ben Nemec <bnemec@redhat.com>
Co-authored-by: Derek Higgins <derekh@redhat.com>
Co-authored-by: Eduardo Minguez Perez <e.minguez@gmail.com>
Co-authored-by: Mark McLoughlin <markmc@redhat.com>
Co-authored-by: Russell Bryant <rbryant@redhat.com>
Co-authored-by: Sandhya Dasu <sdasu@redhat.com>
Co-authored-by: Stephen Benjamin <stephen@redhat.com>
Co-authored-by: Steven Hardy <shardy@redhat.com>
Co-authored-by: Yolanda Robla <yroblamo@redhat.com>
the clustername is a subdomain [1] when we create the private DNS zone ie `clustername.basedomain`
but when creating the public records, clustername is a dns label [1] as we create records under the `basedomain`
So the clustername needs to be valid subdomain but can be max 63 bytes, compared to currently allowed 255 bytes.
[1]: https://tools.ietf.org/html/rfc1123
Add Proxy struct from OpenShift API to Install Config so users can specify cluster-wide proxy configuration. Add basic validation to ensure that the proxy configuration being created is sane.
Jira: CORS-1075
Validate that the cluster name in an InstallConfig is a valid DNS subdomain.
Validate that <cluster-name>.<base-domain> is a valid DNS subdomain.
The DomainName function in pkg/validate now takes a parameter specifying
whether the domain name being validated is permitted to have a trailing dot.
The base domain is allowed to have a trailing dot, but the cluster name is
not allowed to have a trailing dot.
Fix for https://bugzilla.redhat.com/show_bug.cgi?id=1663447
* Add the Network.config.openshift.io CRD
* Generate the network config from the install config
* Remove networkoperator types from install config (but use the same
schema)
* Move network CRDs to templates to match #943
This doesn't change the json/yaml serialization of the install config, but it
changes it internally.
Before this change validation allowed CIDRs with network IP set to any IP address in the range.
This change enforces that CIDR notation use network IP.
example,
```yaml
...
networking:
machineCIDR: 192.168.126.10/24
...
```
The installer now errors on `create cluster`
```console
FATAL failed to fetch Terraform Variables: failed to load asset "Install Config": invalid "install-config.yaml" file: networking.machineCIDR: Invalid value: "192.168.126.10/24": invalid network address. got 192.168.126.10/24, expecting 192.168.126.0/24
```
Previously, destroy support was behind TAGS=libvirt_destroy and create
support was always built in. But since 3fb4400c (terraform/plugins:
add `libvirt`, `aws`, `ignition`, `openstack` to KnownPlugins,
2018-12-14, #919), the bundled libvirt Terraform provider has also
been behind libvirt_destroy. That leads to cluster creation failing
with:
$ openshift-install create cluster
...
ERROR Missing required providers.
ERROR
ERROR The following provider constraints are not met by the currently-installed
ERROR provider plugins:
ERROR
ERROR * libvirt (any version)
ERROR
ERROR Terraform can automatically download and install plugins to meet the given
ERROR constraints, but this step was skipped due to the use of -get-plugins=false
ERROR and/or -plugin-dir on the command line.
...
With this commit, folks trying to 'create cluster' without libvirt
compiled in will get:
FATAL failed to fetch Common Manifests: failed to load asset "Install Config": invalid "install-config.yaml" file: platform: Invalid value: types.Platform{AWS:(*aws.Platform)(nil), Libvirt:(*libvirt.Platform)(0xc4209511f0), OpenStack:(*openstack.Platform)(nil)}: platform must be one of: aws, openstack
before we get to Terraform.
Now that the build tag guards both creation and deletion, I've renamed
it from 'libvirt_destroy' to the unqualified 'libvirt'.
I've also adjusted the install-config validation testing to use
regular expressions so we can distinguish between failures because
libvirt was not compiled in as a valid platform and failures because
some portion of the libvirt configuration was broken. In order to get
stable error messages for comparison, I've added some strings.Sort
calls for various allowed-value string-slice computations.
Much of the code that made of the CIDR validation was there to give a custom
description of what made the CIDR provided invalid. This has been removed in
favor of using the error returned by the golang library's ParseCIDR function.
Additionally, the code to determine whether two CIDRs overlap was unnecessary
complex because it did not take advantage of the fact that CIDRs only overlap
if one is a subset of the other.
https://jira.coreos.com/browse/CORS-850
Move the uri validation from pkg/asset/installconfig/libvirt to pkg/validation
for consistency with other validation functions.
https://jira.coreos.com/browse/CORS-850
Validate that (1) there is an "auths" field, (2) the "auths"
value has fields, and (3) each field in the "auth" value has
an "auth" or a "credsStore" field.
https://jira.coreos.com/browse/CORS-850
Use kubernetes validation of rfc-1123 sub-domains. This change
removes the restriction that each label in the cluster name is at most 63
characters long.
https://jira.coreos.com/browse/CORS-850
Use kubernetes validation of rfc-1123 sub-domains, with the
addition that the base domain can end with a dot. This change removes the
ability to use uppercase letters in the base domain.
https://jira.coreos.com/browse/CORS-850
Alex gave the history behind our previous bucket name [1]:
We should probably just fix the creation of the S3 bucket since we
no longer rely on CNAMEs (which required the S3 bucket to match the
domain name).
But now we can just let AWS pick a random bucket name for us.
I've also dropped the no-longer-used S3Bucket validator.
[1]: https://github.com/openshift/installer/pull/359#issuecomment-426051251
This removes a few Cluster properties which are no longer used by the
new installer. It also drops YAML loading for Cluster now that it's a
one-way map from InstallConfig to Terraform JSON. I've shifted
validation into its own package, since we should be validating these
at the InstallConfig level.
I've also shifted the Terraform variable generation out of pkg/types,
because it's not about public types. I've reduced the variable
generation to a single function.
I've dropped the old Cluster (and subtype) specific validation. We'll
want to add InstallConfig validation once we support loading it from
the disk, but for now we can rely on the UserProvided validation (and
this commit was already large enough ;).
