There is no real reason to do this. In some cases this may even prevent
clusters from starting where there is no explicit volume type defined in
cinder.
This should be much easier to start and to get under testing; it only
works with a load balancer, it sets the apiserver into anonymous-auth
allowed, it grants the anonymous auth user permission to read our jwks
tokens. But it shouldn't need a second bucket or anything of that
nature.
Co-authored-by: John Gardiner Myers <jgmyers@proofpoint.com>
Use provider-agnostic node definition for cas instead of aws auto-discovery
Validate clusterAutoscalerSpec
Add spec documentation
Add cas docs
Make CRDs
Apply suggestions from code review
Co-authored-by: John Gardiner Myers <jgmyers@proofpoint.com>
Add enabled flag to cas config
Apply suggestions from code review
Co-authored-by: Guy Templeton <guyjtempleton@googlemail.com>
Add support for custom cas image
Support more k8s versions
Use full image names
We create a simple exec plugin command which can create and renew
short-lived admin credentials on the fly, essentially leveraging the
security of the underlying cloud credentials.
Co-authored-by: John Gardiner Myers <jgmyers@proofpoint.com>
When the PublicJWKS feature-flag is set, we expose the apiserver JWKS
document publicly (including enabling anonymous access). This is a
stepping stone to a more hardened configuration where we copy the JWKS
document to S3/GCS/etc.
Co-authored-by: John Gardiner Myers <jgmyers@proofpoint.com>
This means we no longer have to individually hard-code the `kops set`
fields, however we use the "language" we're now demonstrated.
We add tests to ensure we have parity with our existing (hard-coded)
setter logic.
We will be managing cluster addons using CRDs, and so we want to be
able to apply arbitrary objects as part of cluster bringup.
Start by allowing (behind a feature-flag) for arbitrary objects to be
specified.
Co-authored-by: John Gardiner Myers <jgmyers@proofpoint.com>
Kops creates an "api.internal.$clustername" dns A record that points to the master IP(s)
This adds a flag that will use that name and force the CA cert to be included.
This is a workaround for client certificate authentication not working on API ELBs with ACM certificates.
The ELB has a TLS listener rather than TCP, so the client certificate is not passed through to the apiserver.
Using --internal will bypass the API ELB so that the client certificate will be passed directly to the apiserver.
This also requires that the masters' security groups allow 443 access from the client which this does not handle automatically.
Ciprian Hacman