Get credentials from GCP/Azure when needed #194

somtochiama · 2021-11-05T12:52:09Z

Closes #180
Closes #179

This pull request adds two flags (gcp-autologin-for-gcr and azure-autologin-for-acr) for autologin on GCP and Azure to their container registries.

This has been tested on GKE clusters with workload identities enabled and default service account.
This has been tested on an AKS w Managed Identities.

Further refactoring could be done to move implementation details of various cloud providers into a dedicated package.

Signed-off-by: Somtochi Onyekwere somtochionyekwere@gmail.com

controllers/imagerepository_controller.go

relu · 2021-11-08T13:58:56Z

This is a note for later but I think it would be better to get these implementations out of the controller, maybe moved to internal.

controllers/imagerepository_controller.go

relu

Looking good, @somtochiama 👍
Added some comments regarding a few minor improvements.

relu · 2021-11-22T12:09:31Z

internal/azure/exchanger.go

+	req, err := http.NewRequest("POST", exchangeUrl, strings.NewReader(parameters.Encode()))
+	if err != nil {
+		return "", fmt.Errorf("error constructing exchange request: %w", err)
+	}
+
+	req.Header.Add("Content-Type", "application/x-www-form-urlencoded")
+	req.Header.Add("Content-Length", strconv.Itoa(len(parameters.Encode())))
+
+	client := &http.Client{}
+	resp, err := client.Do(req)


There's a helper method that can be used for form POSTing in http. Here's the short variant of all of this 😄

Suggested change

req, err := http.NewRequest("POST", exchangeUrl, strings.NewReader(parameters.Encode()))

if err != nil {

return "", fmt.Errorf("error constructing exchange request: %w", err)

}

req.Header.Add("Content-Type", "application/x-www-form-urlencoded")

req.Header.Add("Content-Length", strconv.Itoa(len(parameters.Encode())))

client := &http.Client{}

resp, err := client.Do(req)

resp, err := http.PostForm(exchangeUrl, parameters)

relu · 2021-11-22T12:11:05Z

internal/azure/exchanger.go

+}
+
+type Exchanger struct {
+	scheme   string


Doesn't seem like something that would ever be changed or overridden, should be safe to hardcode this as https in the resulting URL.

relu · 2021-11-22T12:14:55Z

controllers/imagerepository_controller.go

+	var authConfig authn.AuthConfig
+	gcpDefaultTokenURL := "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"
+
+	request, err := http.NewRequest("GET", gcpDefaultTokenURL, nil)


Maybe use the const here

Suggested change

request, err := http.NewRequest("GET", gcpDefaultTokenURL, nil)

request, err := http.NewRequest(http.MethodGet, gcpDefaultTokenURL, nil)

controllers/imagerepository_controller.go

relu

Left just a few more comments.

relu · 2021-11-23T12:16:51Z

internal/azure/exchanger.go

+		return "", fmt.Errorf("failed to send token exchnage request: %w", err)
+	}
+
+	if resp.StatusCode != 200 {


Suggested change

if resp.StatusCode != 200 {

if resp.StatusCode != http.StatusOK {

relu · 2021-11-23T12:27:53Z

internal/azure/exchanger.go

+	}
+
+	if resp.StatusCode != 200 {
+		responseBytes, err := ioutil.ReadAll(resp.Body)


Might be a good idea to not use ioutil.ReadAll here, we don't know how large the response body can be and this can cause memory issues. See my comment below.

Do we know what type of responses we get? If it's JSON maybe we can extract only the relevant bits for the error message. If not, maybe try to only read at a maximum just a few bytes worth of data.

relu · 2021-11-23T12:33:25Z

internal/azure/exchanger.go

+	responseBytes, err := ioutil.ReadAll(resp.Body)
+	if err != nil {
+		return "", fmt.Errorf("failed to read response body: %w", err)
+	}
+
+	var tokenResp tokenResponse
+	err = json.Unmarshal(responseBytes, &tokenResp)


ioutil.ReadAll loads everything into memory and it should be avoided whenever possible. Using the json Decoder would be more efficient.

Suggested change

responseBytes, err := ioutil.ReadAll(resp.Body)

if err != nil {

return "", fmt.Errorf("failed to read response body: %w", err)

}

var tokenResp tokenResponse

err = json.Unmarshal(responseBytes, &tokenResp)

var tokenResp tokenResponse

decoder := json.NewDecoder(resp.Body)

if err := decoder.Decode(&tokenResp); err != nil {

return "", err

}

relu · 2021-11-23T12:48:44Z

internal/azure/exchanger.go

+}
+
+func (e *Exchanger) ExchangeACRAccessToken(armToken string) (string, error) {
+	exchangeUrl := fmt.Sprintf("%s://%s/oauth2/exchange", "https", e.acrFQDN)


Suggested change

exchangeUrl := fmt.Sprintf("%s://%s/oauth2/exchange", "https", e.acrFQDN)

exchangeUrl := fmt.Sprintf("https://%s/oauth2/exchange", e.acrFQDN)

kingdonb · 2021-11-23T13:05:51Z

I've done some testing against the image somma/image-reflector-controller:test-autologin-c34c7cf34b1 on both Azure and GKE, and the feature was working all around for me.

$ flux get image policy -A
NAMESPACE       NAME    READY   MESSAGE                                                                                         LATEST IMAGE                                         
podinfo-staging podinfo True    Latest image tag for 'acrkingdontest.azurecr.io/stefanprodan/podinfo' resolved to: 5.0.0        acrkingdontest.azurecr.io/stefanprodan/podinfo:5.0.0

and on GCP:

$ flux get image policy -A
NAMESPACE               NAME    READY   MESSAGE                                                                 LATEST IMAGE                    
podinfo-production      podinfo True    Latest image tag for 'gcr.io/dx-kingdon/podinfo' resolved to: 5.0.0     gcr.io/dx-kingdon/podinfo:5.0.0

The testing involved was to follow basically the first half of the Image Update guide: create an ImageRepo and ImagePolicy, pointed at the private repository. Remove the flag to confirm that access does not happen without the newly added feature. When the flag is present, there should be no secretRef or other access management required, it should "just work."

I created the Azure cluster in an existing Resource Group through the portal with a "System-Managed Identity" and associated the cluster with a Container Registry on the same RG. I used Azure CNI and Calico policy enforcement, which probably doesn't matter, (but just to be complete) with Kubernetes 1.21 under the hood. The image repo created was definitely private. I used the Quickstart guide from Azure docs to "build and push" some example Podinfo images FROM stefanprodan/podinfo:5.0.0.

https://docs.microsoft.com/en-us/azure/container-registry/container-registry-quickstart-task-cli

The Dockerfiles for example are in here: https://github.com/kingdonb/bootstrap-repo/tree/main/apps/base/podinfo - they are very sparse. I just needed two images so I could confirm they were both discovered successfully when the ImageRepo is reconciled.

I did the same test on GCR basically, creating a GKE cluster with Workload Identity enabled, then building the same images from the tutorial for Google Cloud Build. This testing method made it possible for me to avoid using my local network or any local build nodes 👍 I placed the images in a new repository in the same project-id that my cluster was created in. I assume this is using the new "Artifact Registry" protocol but I haven't looked deeply into it yet. (Maybe separate validation is still needed for that.) I just used the most obvious docs and searched for anything that I didn't know, I'm only marginally familiar with both cloud vendors.

https://cloud.google.com/build/docs/building/build-containers

The Workload Identity automatically authorized the project repository in the same workspace (project) and as I was able to push images with the gcloud client, that were then discovered without issue by the image-reflector-controller, with a set of manifests in and centered around this one: https://github.com/kingdonb/bootstrap-repo/blob/main/apps/production/podinfo/imagerepo.yaml

After confirming these both worked successfully with the flags:

https://github.com/kingdonb/bootstrap-repo/blob/75fc7f8822f1850d4046700ce4281c39ac5e4bfd/clusters/gke-geekingdon/flux-system/kustomization.yaml#L16
and
https://github.com/kingdonb/bootstrap-repo/blob/75fc7f8822f1850d4046700ce4281c39ac5e4bfd/clusters/aks-kuberkingdon/flux-system/kustomization.yaml#L16

I'm happy to report the feature works without issue on both of these! Removing the flag made for an authentication error that looked reasonable, (I didn't capture it.) I'll be repeating the testing later today, in case there are any questions or issues in the critical path that other reviewers wanted to make sure are properly addressed. Please let me know.

internal/azure/exchanger.go

relu

Great, thank you @somtochiama! 💯

relu · 2021-11-23T19:15:42Z

Could you please also resolve the conflicts?

kingdonb · 2021-11-23T20:14:30Z

I have some surprising results after testing further on GKE,

I created a new cluster and enabled Workload Identity, but the reflector controller can no longer reach the auth, or something else has gone wrong:

{"level":"error","ts":"2021-11-23T20:02:18.456Z","logger":"controller-runtime.manager.controller.imagepolicy","msg":"Reconciler error","reconciler group":"image.toolkit.fluxcd.io","reconciler kind":"ImagePolicy","name":"podinfo","namespace":"podinfo-production","error":"version list argument cannot be empty"}
{"level":"info","ts":"2021-11-23T20:02:21.686Z","logger":"controller-runtime.manager.controller.imagerepository","msg":"Logging in to GCP GCR for gcr.io/dx-kingdon/podinfo","reconciler group":"image.toolkit.fluxcd.io","reconciler kind":"ImageRepository","name":"podinfo","namespace":"podinfo-production"}
{"level":"error","ts":"2021-11-23T20:02:21.878Z","logger":"controller-runtime.manager.controller.imagerepository","msg":"Reconciler error","reconciler group":"image.toolkit.fluxcd.io","reconciler kind":"ImageRepository","name":"podinfo","namespace":"podinfo-production","error":"GET https://gcr.io/v2/dx-kingdon/podinfo/tags/list?n=1000: DENIED: Failed to read tags for host 'gcr.io', repository '/v2/dx-kingdon/podinfo/tags/list?n=1000'"}
{"level":"info","ts":"2021-11-23T20:03:59.667Z","logger":"controller-runtime.manager.controller.imagerepository","msg":"Logging in to GCP GCR for gcr.io/dx-kingdon/podinfo","reconciler group":"image.toolkit.fluxcd.io","reconciler kind":"ImageRepository","name":"podinfo","namespace":"podinfo-production"}
{"level":"error","ts":"2021-11-23T20:03:59.693Z","logger":"controller-runtime.manager.controller.imagepolicy","msg":"Reconciler error","reconciler group":"image.toolkit.fluxcd.io","reconciler kind":"ImagePolicy","name":"podinfo","namespace":"podinfo-production","error":"version list argument cannot be empty"}
{"level":"error","ts":"2021-11-23T20:03:59.875Z","logger":"controller-runtime.manager.controller.imagerepository","msg":"Reconciler error","reconciler group":"image.toolkit.fluxcd.io","reconciler kind":"ImageRepository","name":"podinfo","namespace":"podinfo-production","error":"GET https://gcr.io/v2/dx-kingdon/podinfo/tags/list?n=1000: DENIED: Failed to read tags for host 'gcr.io', repository '/v2/dx-kingdon/podinfo/tags/list?n=1000'"}

This while the images can be deployed in the cluster, so apparently the project association is correct, something else has gone wrong.

I suspect this is probably a configuration error, although I'm not sure what can have gone wrong, I have the flag enabled and my image is at:

images: # []
- name: ghcr.io/fluxcd/image-reflector-controller
  newName: docker.io/somma/image-reflector-controller
  newTag: test-autologin-c34c7cf34b1

but the registry cannot be scanned for ImageRepository resources. Is there somewhere else to check for debugging errors?

kingdonb · 2021-11-23T20:28:58Z

@somtochiama sent me some docs about Workload Identity that I hadn't seen before. It looks like my previous test was not using workload identity, but the default service account instead. I will go back and repeat it after I work out my Workload Identity issues to confirm. Anyway just to add to this report, my configuration issue is definitely a configuration issue.

somtochiama · 2022-01-11T09:54:37Z

I am adding some notes here for testing this on GCP. I will write more detailed documentation next and make a commit.

Enable Workload Identiy on the cluster (Docs: https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#enable_on_cluster. If you have an existing cluster, don't forget to migrate applications to workload identity. See https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#migrate_applications_to
Create a GCP service account that has access to GCR
Bind the GCP service account to the image-reflector-controller service account (Docs)
Customize the flux manifest so that it uses the image from this pull request and also annotates the image-reflector-controller service account with the iam.gke.io/gcp-service-account label

Example of gotk-patches.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: image-reflector-controller
  namespace: flux-system
spec:
  template:
    spec:
      containers:
      - name: manager
        image: somma/image-reflector-controller:test-autologin-d5255a590
        args:
          - --events-addr=http://notification-controller.flux-system.svc.cluster.local/
          - --watch-all-namespaces
          - --log-level=info
          - --log-encoding=json
          - --enable-leader-election
          - --gcp-autologin-for-gcr
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: image-reflector-controller
  namespace: flux-system
  annotations:
    iam.gke.io/gcp-service-account: "service-account-name@project-id.iam.gserviceaccount.com"

stefanprodan · 2022-01-11T10:44:19Z

The bootstrap docs along with #193 should be placed in https://fluxcd.io/docs/guides/image-update/#imagerepository-cloud-providers-authentication

squaremo

Solid work @somtochiama, thank you. I've made a few suggestions and raised some questions -- nothing drastic, so I've approved this PR.

(The first commit seems to have a duplicate sign-off -- something to amend if you end up doing further work here.)

controllers/imagerepository_controller.go

squaremo · 2022-01-12T10:05:23Z

controllers/imagerepository_controller.go

+	}, nil
+}
+
+// List from https://github.com/kubernetes/kubernetes/blob/master/pkg/credentialprovider/azure/azure_credentials.go


Probably better to link to the code at a specific revision, or (more readably) a release tag, otherwise it can change out from under you.

.github/workflows/scan.yml

squaremo · 2022-01-12T10:07:49Z

controllers/imagerepository_controller.go

+	ClientCert               = "certFile"
+	ClientKey                = "keyFile"
+	CACert                   = "caFile"
+	azureCloudConfigJsonFile = "/etc/kubernetes/azure.json"


This const isn't mentioned in the rest of the diff -- perhaps it's a holdover from the "mount the file from the host" code?

squaremo · 2022-01-12T10:32:06Z

controllers/imagerepository_controller.go

+	if err != nil {
+		return authConfig, err
+	}
+


Provided Do didn't return an error, you should Close() the response body, and probably read it to the end too (see the comment in https://pkg.go.dev/net/http#Client.Do). You can do io.Copy(io.Discard, response.Body) (or perhaps better, io.Copy(io.Discard, &io.LimitedReader{R: response.Body, N: maxResponseLength}) for some maxResponseLength).

You should really do this in all cases other than getting an error back from Do. As it stands, the body will only be read to the end and closed if the status was OK and a JSON value could be decoded; but, it's entirely possible, e.g., that a 40x status would have body content.
It's a pain I know, because you are forced to either repeat code or defer (and throw away errors) -- since no (other) I/O happens after the request, I think using defer is fine.

squaremo · 2022-01-12T10:42:17Z

controllers/imagerepository_controller.go

+
+// getAzureLoginAuth returns authentication for ACR. The details needed for authentication
+// are gotten from environment variable so there is not need to mount a host path.
+func getAzureLoginAuth(ref name.Reference) (authn.AuthConfig, error) {


I think it would be wise to pass the context from Reconcile through to this func, for it to use in requests (and likewise for the GCR -- and ECR, for that matter). What do you think?

I think so too.

squaremo · 2022-01-12T10:45:25Z

docs/spec/v1beta1/imagerepositories.md

+
+For  [<abbr title="Elastic Kubernetes Service">EKS</abbr>][EKS] and [<abbr title="Elastic Container Registry">ECR</abbr>][ECR], 
+the flag is `--aws-autologin-for-ecr`.
+For [<abbr title="Googke Kubernetes Enginer">GKE</abbr>][GKE] and [<abbr title="Google Container Registry">GCR</abbr>][GCR],


Suggested change

For [<abbr title="Googke Kubernetes Enginer">GKE</abbr>][GKE] and [<abbr title="Google Container Registry">GCR</abbr>][GCR],

For [<abbr title="Google Kubernetes Engine">GKE</abbr>][GKE] and [<abbr title="Google Container Registry">GCR</abbr>][GCR],

<3 for using <abbr> consistently!

squaremo · 2022-01-12T10:46:34Z

docs/spec/v1beta1/imagerepositories.md

+the flag is `--aws-autologin-for-ecr`.
+For [<abbr title="Googke Kubernetes Enginer">GKE</abbr>][GKE] and [<abbr title="Google Container Registry">GCR</abbr>][GCR],
+the flag is `--gcp-autologin-for-gcr`.
+For [<abbr title="Azure Kubernetes Service">AKS</abbr>][AKS] and [<abbr title="Azure Container Registry">EKS</abbr>][ACR],


Suggested change

For [<abbr title="Azure Kubernetes Service">AKS</abbr>][AKS] and [<abbr title="Azure Container Registry">EKS</abbr>][ACR],

For [<abbr title="Azure Kubernetes Service">AKS</abbr>][AKS] and [<abbr title="Azure Container Registry">ACR</abbr>][ACR],

So .. many .. TLAs ... 😄
(to be clear, I'm commenting on Tech, not on the docs here)

internal/azure/exchanger.go

.github/workflows/scan.yml

go.mod

kingdonb · 2022-01-14T15:48:30Z

It's noted elsewhere, but following up that I have tested GKE Workload Identity to connect with gcr.io registries successfully

However I was not able to get artifact registry working through workload identity, even after separately granting the role for role/artifactregistry.reader I still get this error:

podinfo-artifact-registry	False	GET https://us-central1-docker.pkg.dev/v2/token?scope=repository%3Adx-kingdon%2Fgeekingdon-images%2Fpodinfo%3Apull&service=us-central1-docker.pkg.dev: DENIED: Permission "artifactregistry.repositories.downloadArtifacts" denied on resource "projects/dx-kingdon/locations/us-central1/repositories/geekingdon-images" (or it may not exist)	                         	False

I guess the culprit is here: https://github.com/fluxcd/image-reflector-controller/pull/194/files#diff-922fcbfbe2565443329918a2b0d49b2b03588007ec6464a20d3feb824f3f80a2R735-R737

it needs to match pkg.dev as well (and possibly others), else artifact registry won't be considered as the same as container registry. I'm giving it a shot and testing it on my own, I think I have everything I need to compile a version of image-reflector-controller 👍

kingdonb · 2022-01-14T16:07:42Z

Yey, that worked:

$ flux get image repository
NAME                     	READY	MESSAGE                      	LAST SCAN                	SUSPENDED
podinfo                  	True 	successful scan, found 2 tags	2022-01-14T10:58:16-05:00	False
podinfo-artifact-registry	True 	successful scan, found 2 tags	2022-01-14T10:58:16-05:00	False

Some research indicates artifact registry OCI addresses for GCP will always be of the form *-docker.pkg.dev

Here is the commit that enables artifact registry, if you'd like to pull it into your branch:

kingdonb/image-reflector-controller:2eb0be8

kingdonb@2eb0be8

The page that clued me into the structure is here, https://cloud.google.com/artifact-registry/docs/access-control – it would be good to have a more canonical source than that, as there may still be other addresses that can host Artifact Registry and they will not work without further changes. Hopefully this address format is invariant and we can count on it everywhere 🤷

I tested this version and it works with both gcr.io and *-docker.pkg.dev so covers both the old GCR (deprecated) and the new "Artifact Registry" successor, which I haven't heard much about (but couldn't avoid tripping over in the GCP New User onboarding workflows. It's pretty clear they don't want you to use gcr.io anymore.)

kingdonb · 2022-01-14T16:14:02Z

The other thing I might want to add to the docs:

gcloud projects add-iam-policy-binding <PROJECT> --member "serviceAccount:<GCP-SA-NAME>@<PROJECT>.iam.gserviceaccount.com" --role roles/artifactregistry.reader
gcloud projects add-iam-policy-binding <PROJECT> --member "serviceAccount:<GCP-SA-NAME>@<PROJECT>.iam.gserviceaccount.com" --role roles/containerregistry.ServiceAgent

It was not very difficult to discover these roles, but we can help the users by spelling it out.

I'm not sure I have selected the minimal roles either. There is no containerregistry.reader to go with artifactregistry.reader, only containerregistry.ServiceAgent, and after applying both of the roles I found (and possibly some others, who knows exactly what I did here, I'm not 100%), I wind up with this set of bindings which seems like it might likely be in excess of what I needed:

Updated IAM policy for project [dx-kingdon].
bindings:
- members:
  - serviceAccount:kingdon-test-gcr-sa@dx-kingdon.iam.gserviceaccount.com
  role: roles/artifactregistry.reader
- members:
  - serviceAccount:service-1041773995540@gcp-sa-artifactregistry.iam.gserviceaccount.com
  role: roles/artifactregistry.serviceAgent
- members:
  - serviceAccount:1041773995540@cloudbuild.gserviceaccount.com
  role: roles/cloudbuild.builds.builder
- members:
  - serviceAccount:service-1041773995540@gcp-sa-cloudbuild.iam.gserviceaccount.com
  role: roles/cloudbuild.serviceAgent
- members:
  - serviceAccount:service-1041773995540@compute-system.iam.gserviceaccount.com
  role: roles/compute.serviceAgent
- members:
  - serviceAccount:service-1041773995540@container-engine-robot.iam.gserviceaccount.com
  role: roles/container.serviceAgent
- members:
  - serviceAccount:kingdon-test-gcr-sa@dx-kingdon.iam.gserviceaccount.com
  - serviceAccount:service-1041773995540@containerregistry.iam.gserviceaccount.com
  role: roles/containerregistry.ServiceAgent
- members:
  - serviceAccount:1041773995540-compute@developer.gserviceaccount.com
  - serviceAccount:1041773995540@cloudservices.gserviceaccount.com
  role: roles/editor
- members:
  - user:kingdon@weave.works
  role: roles/owner
- members:
  - serviceAccount:service-1041773995540@gcp-sa-pubsub.iam.gserviceaccount.com
  role: roles/pubsub.serviceAgent
etag: BwXVjQ36L8E=
version: 1

Someone who knows GCP well enough to say how to select the minimal roles should review that information for correctness.

(Perhaps the nasty mess of roles required just to get "container registry / reader" access is part of the motivation to deprecate gcr.io - I'm not sure if I'm the one that added cloud build role or if it came with containerregistry.ServiceAgent but push access is something that we definitely don't need here, and it's obvious how to set that up for artifact registry, but not so clear at least as a beginner, with all the different role primitives associated with the gcr agent role.)

kingdonb · 2022-01-14T16:26:45Z

This was the doc from GCP re: Workload Identity that gave the most clarity about what roles were available and what role primitives composed them: https://cloud.google.com/iam/docs/understanding-roles#predefined_roles

stefanprodan · 2022-01-20T07:49:15Z

@somtochiama can you please rebase and run make fmt.

Signed-off-by: Somtochi Onyekwere <somtochionyekwere@gmail.com> Signed-off-by: Somtochi Onyekwere <somtochionyekwere@gmail.com>

stefanprodan

LGTM

Thanks @somtochiama 🏅

squaremo

Thanks for following through on my comments -- one adjustment, then I think this is good to go.

squaremo · 2022-01-20T10:22:47Z

controllers/imagerepository_controller.go

+	if err != nil {
+		return authConfig, err
+	}
+


You should really do this in all cases other than getting an error back from Do. As it stands, the body will only be read to the end and closed if the status was OK and a JSON value could be decoded; but, it's entirely possible, e.g., that a 40x status would have body content.
It's a pain I know, because you are forced to either repeat code or defer (and throw away errors) -- since no (other) I/O happens after the request, I think using defer is fine.

stefanprodan · 2022-01-20T10:29:28Z

@somtochiama can you please open a new PR to address @squaremo comment, sorry I missed it.

relu reviewed Nov 8, 2021

View reviewed changes

controllers/imagerepository_controller.go Outdated Show resolved Hide resolved

somtochiama changed the title ~~Get credentials from GCP when needed~~ Get credentials from GCP/Azure when needed Nov 9, 2021

hiddeco reviewed Nov 9, 2021

View reviewed changes

controllers/imagerepository_controller.go Outdated Show resolved Hide resolved

somtochiama marked this pull request as ready for review November 10, 2021 16:40

somtochiama requested review from relu and hiddeco November 22, 2021 09:06

squaremo self-requested a review November 22, 2021 10:44

relu requested changes Nov 22, 2021

View reviewed changes

relu requested changes Nov 23, 2021

View reviewed changes

stefanprodan requested changes Nov 23, 2021

View reviewed changes

internal/azure/exchanger.go Outdated Show resolved Hide resolved

relu approved these changes Nov 23, 2021

View reviewed changes

somtochiama force-pushed the gcp-autologin branch from 24233a1 to 59cea8a Compare November 23, 2021 20:42

somtochiama force-pushed the gcp-autologin branch from 59cea8a to cffd1ff Compare December 3, 2021 14:19

somtochiama force-pushed the gcp-autologin branch from cffd1ff to d5255a5 Compare January 11, 2022 09:28

somtochiama mentioned this pull request Jan 11, 2022

Add docs for autologin(ACR/ECR/GCR) fluxcd/website#702

Merged

squaremo approved these changes Jan 12, 2022

View reviewed changes

stefanprodan reviewed Jan 12, 2022

View reviewed changes

.github/workflows/scan.yml Outdated Show resolved Hide resolved

stefanprodan reviewed Jan 12, 2022

View reviewed changes

go.mod Outdated Show resolved Hide resolved

somtochiama requested a review from squaremo January 13, 2022 09:26

kingdonb mentioned this pull request Jan 14, 2022

Clarify ECR Auto-login note, fix CanonicalImageName typos #219

Merged

stefanprodan mentioned this pull request Jan 20, 2022

Prepare Flux v0.26.0 release fluxcd/flux2#2308

Closed

24 tasks

Implement autologin for GCP and Azure

fcd6c92

Signed-off-by: Somtochi Onyekwere <somtochionyekwere@gmail.com> Signed-off-by: Somtochi Onyekwere <somtochionyekwere@gmail.com>

somtochiama force-pushed the gcp-autologin branch from 44325e6 to fcd6c92 Compare January 20, 2022 09:17

stefanprodan approved these changes Jan 20, 2022

View reviewed changes

stefanprodan added the enhancement New feature or request label Jan 20, 2022

stefanprodan merged commit 4ca33b4 into fluxcd:main Jan 20, 2022

squaremo requested changes Jan 20, 2022

View reviewed changes

somtochiama mentioned this pull request Jan 20, 2022

GCR fix: Discard and close body regardless of status code #224

Merged

darkowlzz mentioned this pull request Oct 22, 2024

Enable standard forms of GCP auth for oci sources fluxcd/pkg#815

Open

	request, err := http.NewRequest("GET", gcpDefaultTokenURL, nil)
	request, err := http.NewRequest(http.MethodGet, gcpDefaultTokenURL, nil)

	if resp.StatusCode != 200 {
	if resp.StatusCode != http.StatusOK {

	exchangeUrl := fmt.Sprintf("%s://%s/oauth2/exchange", "https", e.acrFQDN)
	exchangeUrl := fmt.Sprintf("https://%s/oauth2/exchange", e.acrFQDN)

	For [<abbr title="Googke Kubernetes Enginer">GKE</abbr>][GKE] and [<abbr title="Google Container Registry">GCR</abbr>][GCR],
	For [<abbr title="Google Kubernetes Engine">GKE</abbr>][GKE] and [<abbr title="Google Container Registry">GCR</abbr>][GCR],

	For [<abbr title="Azure Kubernetes Service">AKS</abbr>][AKS] and [<abbr title="Azure Container Registry">EKS</abbr>][ACR],
	For [<abbr title="Azure Kubernetes Service">AKS</abbr>][AKS] and [<abbr title="Azure Container Registry">ACR</abbr>][ACR],

Get credentials from GCP/Azure when needed #194

Get credentials from GCP/Azure when needed #194

Conversation

somtochiama commented Nov 5, 2021 • edited Loading

relu commented Nov 8, 2021

relu left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

relu left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kingdonb commented Nov 23, 2021

relu left a comment

Choose a reason for hiding this comment

relu commented Nov 23, 2021

kingdonb commented Nov 23, 2021

kingdonb commented Nov 23, 2021

somtochiama commented Jan 11, 2022 • edited Loading

stefanprodan commented Jan 11, 2022

squaremo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kingdonb commented Jan 14, 2022

kingdonb commented Jan 14, 2022 • edited Loading

kingdonb commented Jan 14, 2022 • edited Loading

kingdonb commented Jan 14, 2022

stefanprodan commented Jan 20, 2022

stefanprodan left a comment

Choose a reason for hiding this comment

squaremo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stefanprodan commented Jan 20, 2022

somtochiama commented Nov 5, 2021 •

edited

Loading

somtochiama commented Jan 11, 2022 •

edited

Loading

kingdonb commented Jan 14, 2022 •

edited

Loading

kingdonb commented Jan 14, 2022 •

edited

Loading