Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation: Self Managed Cluster #1117

Open
cameronclaero opened this issue Sep 15, 2023 · 4 comments
Open

Documentation: Self Managed Cluster #1117

cameronclaero opened this issue Sep 15, 2023 · 4 comments
Labels
bug Something isn't working

Comments

@cameronclaero
Copy link

I am attempting at getting this set up on a private kubernetes cluster, and have got to this part in the docs:

https://azure.github.io/azure-workload-identity/docs/installation/self-managed-clusters/configurations.html

It lists the configuration flags, but does indicate what they should be set to, (am assuming private/public keys) that were generated previously. It would be helpful to show the values that should be set as examples, to ensure the right values are being set.

@cameronclaero cameronclaero added the bug Something isn't working label Sep 15, 2023
@cameronclaero cameronclaero changed the title Documentation: Documentation: Self Managed Cluster Sep 15, 2023
@osnabrugge
Copy link

osnabrugge commented Sep 23, 2023

@cameronclaero Did you ever get clarity on this? For k8s, this is the best description I have found.

It is a bit of a concern for me as I am using k3s. Not much information that I can find besides replacing the self-signed CA / certs with your own. I personally would rather leave k3s to do it's own cert management and just leverage this additional certificate for the purposes of OIDC with Azure.

Digging into the default behavior of k3s, those flags are already set and leveraging certificates the installer creates / rotates automatically. I am not clear if manually setting these flags will override or use both the default certs and the one we manually create (latter is obviously preferred).

For example, service-account-signing-key-file is already set to service.currentkey which service.currentkey is generated during install

This also might be something specific to k3s, although it is a distribution and not a fork and I would expect behavior of setting these flags to be the same. The only difference that I see from the default behavior is the file locations, where Kubernetes is /etc/kubernetes/pki/ vs k3s of /var/lib/rancher/k3s/server/tls/.

@haodeon
Copy link

haodeon commented Jan 4, 2024

After several days hacking away, today I successfully installed it on minikube.

For minikube I only needed two apiserver flags service-account-issuer and service-account-jwks-uri.

I kept the certs minikube generates instead of replacing them. To get the jwks I used kubectl get —raw.

For anyone interested in more detail, it’s here as a Pulumi program.

@mxrss2
Copy link

mxrss2 commented Jan 28, 2024

Agree this documentation is not well though out and needs a lot of work -- example the azwi cli flags are plain wrong in teh self managed part. --output-file is the correct flag. Also it seems like this is missing a lot of context and its not quite clear what to do -- when using the endpoint i assume it is based on the example the workloads just straight up crash.

@dozer75
Copy link

dozer75 commented Apr 19, 2024

I found this example here in the help pages how to do it using Kind.. Maybe that will help?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants