I've seen articles such as this one about pulling from private repos and the "best" way to do it. What I understand is, if I want to automate any infrastructure to pull my docker images from dockerhub I need to:
Have a user I can login with.
Save the users creds in some application that will spin up my infrastructure (be it EC2 User data, a config file for ansible, or ENV variables in some API).
When the machine spins up it uses this user's credentials to login and place a token on the machine. All is well.
I'm wondering if there is any functionality to use application keys / tokens instead of needing to tie this to a user. It seems like it would be more secure/convenient if I could manage application keys to do have access to my user/organization's DockerHub account. Then I could yank the keys or change my password and not worry about the sky falling.
Is something like this available, coming, or is there a solution I haven't come across yet?
Thanks!
Related
Suppose I have a simple node backend application which when ran needs to connect to a specific GSuite instance, query some things (users, groups, etc.) and then close and not run again until needed, which can mean either a very long time or a few seconds. From what I gathered from Google's documentation there may be multiple ways of doing this, including having an OAuth client and follow the whole flow in setting it up, managing token lifecycle, etc.
However I do NOT want to go with this option for now for various reasons and I am wondering if there is any way of getting access by means of an API Key / secret, like many other 3rd party services allow nowadays. Simply put I would like to generate a key pair somewhere on GSuite, no idea where, and use those keys for auth instead of OAuth, something Google suggests is possible, both on the GSuite Admin app (with a broken link that leads nowhere - not surprising) and on GCloud API and Credentials subpage where you setup credentials (however there it says that API Keys can only be used for very limited resources, none of them having anything to do with GSuite).
I think your best option is to see if what you want to do can be done by a service account. You can create a service account, grant administrator privileges to it in GSuite, enable some APIs, and then that account can do a lot of things without using OAuth directly. The credentials for the service account can then be provided to your application as a json key file, which it can use to authenticate to GSuite. You can also grant service accounts permissions to specific objects like files in Drive, but it doesn't sound like that would be sufficient to your needs.
A guide that may be helpful in the details of how to do this is https://m.fin.com/2017/10/04/navigating-the-google-suite-directory-api/
Is there way to let the user who installs a GitHub App generate a permanent installation access token which can be used by the app to authenticate and perform actions as that app?
I am wanting to create a simple GitHub App that will run on a CI server and comment on PRs with data from one of the tests.
As this app is being run by the user on their CI server there is no place to store the private key for the GitHub App that would usually be used to generate the access token as described here.
Ideally if the user could generate a permanent installation access token for the app they could securely provide that key to the app when it runs on the CI server so the app can communicate with the GitHub API and authenticate as the app.
I realize that the user could provide a user access token and the app could authenticate that way - but when the app comments it needs to show up as originating from the app, not the user (and I don't believe that would happen if the app authenticates with a user access token).
I think you might be confusing "GitHub Apps" with the more generic idea of tools that access the GitHub API. The Apps system a specific way to build hosted services for GitHub that has its own authentication model. Users can't run an App themselves as it is only designed around hosted/SaaS tooling. For things that someone would run themselves, you would need the end user to create a new user account on GitHub for the bot and then authenticate as it (either OAuth or personal access token, doesn't matter).
This is an old question, but in the interest of having the correct info here...
#osowskit's answer is correct in terms of mentioning you need to use JWT but not in terms of that has to be done using webhooks. There are indeed advantages of using Apps for access control - the GitHub App can be given specific access for only some repos. Now at least some CI systems (well at least Jenkins) support GitHub App access natively for some uses.
The basic flaw in the original request was the request of a permanent PAT associated with the App. This is not how they work. Instead you generate a Private Key for the App and it is this that should be stored in the CI secrets system. Now you do indeed need some sort of PAT to actually do the action - here to add the PR comment - it is just that you don't have a permanent one. Instead you generate temporary PATs each time you need to run - IIRC these PATs last for about an hour, so are useful for most single jobs but are to be generated each time and not stored as such.
Once you get the code, it is no big deal using the jwt tokens - it just involves a couple of extra REST calls.
Is there way to let the user who installs a GitHub App generate a permanent installation access token which can be used by the app to authenticate and perform actions as that app?
Maybe but it shouldn't be necessary. A GitHub App will only perform actions on data a user grants it access to. Any data modified on GitHub by the App will appear as an action 'performed' by the App.
Ideally if the user could generate a permanent installation access token for the app they could securely provide that key to the app when it runs on the CI server so the app can communicate with the GitHub API and authenticate as the app.
This shouldn't be necessary based on the information you've provided. Users grant access to a GitHub App to access specific resources and listen for specific events; a GitHub App needs a installation ID (or multiple installation IDs) to interact with GitHub data.
The good news is that for the CI workflow you outlined, GitHub would send the installation ID in the webhook payload - likely a push event.
I realize that the user could provide a user access token and the app could authenticate that way - but when the app comments it needs to show up as originating from the app, not the user (and I don't believe that would happen if the app authenticates with a user access token).
Generating a personal access token (PAT) isn't required and GitHub Apps were created to avoid creating service accounts or adding credentials to your CI environment.
Author your GitHub App to listen for webhook events.
On receiving an event, parse the payload for the installation id
Generate an installation access token by authenticating as an application after creating a JWT.
Use the installation access token generated above to modify data. Note that this token expires in an hour.
Profit!
Are there step by step instructions anywhere on how to generate a "ticket" for an iCloud user given their username/password. I'd like to build a service that access iCloud data (server to server) without having to store the iCloud username or password.
My understanding is that you use the username/password to generate a Kerberos ticket from iCloud. That's based on the answer to How does Sunrise for iOS use iCloud credentials to access our calendar? . But I haven't found instructions online on how to do that.
Does anyone know how to do that? Thanks!
Let me start by pointing out that by default iCloud app storage is "sandboxed" in containers. A signed application can only access its own container without having the API key to authenticate to other application containers. You can make multiple applications share the same container, or use multiple containers in the same application if needed, but essentially you have to be the developer of all applications or have explicit permission to do this. Check out Incorporating iCloud into your app and Enabling CloudKit for more details.
Other (non-appstore) applications and services can authenticate to use an application's data via CloudKit Web Services:
Authenticating to iCloud (redirect based, so credentials still are never revealed and are known only by the user and iCloud server itself);
Further authenticating with your application API key;
The process is described in detail here, as already kindly pointed out by Adam Taylor.
All the above being said, If I understand correctly, you want to have access to all of the user's iCloud data. I think, you won't be able to do so for multiple reasons:
Data is protected by application key, so you need to have this to access a container in addition to the basic credentials;
I'm sure that Apple has a design policy to never ask for user credentials in plain text. Asking the user explicitly for credentials will be against their policy and even if it turns out it is not, having the credentials won't help you much, because you have to enter/send them somewhere. But all iCloud authentication mechanisms are designed to ask for authentication only by the end-user.
This is why I don't believe it is possible to just use user credentials and get access to all of their iCloud data. Now, my 2 cents on why Sunrise works:
As far as I understand, the Sunrise application works, because the calendar data is designed to be shared via CalDav, that works on a concrete URL, so you can import and link your calendar in various calendar client applications. The URL can be found out with a bit of investigation. CalDAV is kind of similar to IMAP and POP3 for mailbox access.
Be so kind to elaborate a bit more on what kind of data you're trying to extract (apple application specific, developer application specific, documents, key-value pairs or something else) and me or other users might help you further.
I've successfully built a ruby script and a mac app that use service account credentials to authenticate (without user interaction) to google cloud storage and upload/download objects.
I now need to perform similar actions on an iOS device. Is it possible to use installed application credentials to authenticate still without user interaction?
If it's possible or has been done, can you please provide an example or point me in the right direction.
Thanks!
You need the private key for the service account to get the access token for the application. Please bear in mind that some hacker may steal that private key for both mac and iOS app. If the data is per user and you have a backend server, you may authenticate the user on the backend and then use the private key on the server to access the storage. If the data is per app, seems there is no good way to prevent the private key abuse.
Goal:
I want do write an application that can trigger Jenkins jobs and itself also authenticates users against the Crowd server. The users must be in a separate crowd group to be authorized to act on Jenkins.
Setup:
I am using the Crowd2 plugin to authenticate Jenkins users against an Atlassian Crowd 2.1 server.
My thoughts:
Now, Jenkins has two types of remote execution:
Jenkins REST API (uses a per-user Token for authentication)
A build can be triggered through this call using a "TOKEN" in a way like this:
JENKINS_URL/job/JOBNAME/build?token=TOKEN
Jenkins CLI (uses an SSH key for authentication)
A build can be triggered through an command line tool using the SSH private key to authenticate the user.
The token-approach (REST API)...
... requires my application to know the API token.
How could I bypass the API token limitation?
Storing the API token within Crowd?
The Crowd2 Jenkins plugin could store the Jenkins API token as an crowd attribute (user-defined properties which can be stored within the crowd user directory), is one way. Even though I think this could be a security flaw, as the attribute might be retrieved from all other applications registered at Crowd (which would enable them to execute Jenkins jobs on the users behalf).
Q: Good approach and secure enough? In my opinion, this is not secure enough.
Authenticating with my applications crowd token against Jenkins?
I've also tried generating a crowd-token through Crowd's API and then requesting the Jenkins REST API with that token as Cookie in the hope that the Jenkins crowd2 plugin validates the passed Crowd token against Crowd. But it does not work (when using the crowd token from my browser, by examining the page information in Firefox, it works, of course).
I am not sure if this approach (if the crowd2 plugin would check the passed token) has security flaws in it and if the crowd-token mechanism is designed to work in that way. I am sure though, that it might negatively affect Jenkins' performance as every API request has to check if the token is valid.
Q: Good approach and possible?
The CLI-approach...
...requires my application to know a SSH private key registered at Jenkins.
It would be good approach, if Jenkins would support adding SSH Keys. My application could generate a SSH key pair (with random) password and automatically store the public key on the users behalf within Jenkins.
I think this is the right way, even though it requires to extend Jenkins and maybe the authentication plugins.
Q: Is this approach possible and secure enough?
Q: Are there other approaches?
I think Jenkins should implement an OAuth endpoint for authorization (in case of the crowd plugin, it then has to delegate the authorization to Crowd) or completely detach user management from its core. Am I wrong?
Please help me improving this question, if neccessary. I can imagine that I've mixed two problems and didn't described by goal clear enough.
Note: Edited this question ~1 hr after creation (see my 1st comment).