Searching through the Internet, I have seen that EKS only enables IAM authentication for IAM users.
Is it possible to configure client certificate authentication manually? I mean, create Kubernetes users and roles internally and not use IAM authentication.
Kubernetes supports several authentication modules, for example:
X509 client certificates
Service account tokens
OpenID Connect tokens
Webhook token authentication
Authenticating proxy, etc.
You can find more details regarding them in the official documentation.
However, Amazon EKS uses only one specific authentication method, an implementation of a webhook token authentication to authenticate Kube API requests. This webhook service is implemented by an open source tool called AWS IAM Authenticator, which has both client and server sides.
In short, the client sends a token (which includes the AWS IAM identity—user or role—making the API call) which is verified on the server-side by the webhook service.
So the answer to your question is: if you choose to use EKS you only have one authentication option which is IAM.
I hope it helps.
Related
I have an AWS REST API Gateway with Cognito authentication using the client credentials grant.
We have been creating new clients by hand and sharing the ID/secret with people who need to use our API. They send the ID/secret and "grant_type=client_credentials" to Cognito, it gives them a bearer token and they use the API with the token. All fine so far. (It is a CLI tool running on a schedule, not accessed by a browser. I specifically need to avoid any sort of "go to the browser to login".)
Now, we have a new "island" of users who have a local OIDC (Azure AD) provider that can issue them a bearer token from a curl to an endpoint.
Is there a way to make Cognito accept those tokens??
I have tried federating Cognito with a different oidc provider (I don't have AD, but a different provider), getting myself a bearer token from it and sending it to the API GW, and I just get 401'ed. I don't know if there is something I'm doing wrong or if it's not possible.
(Things I might be doing wrong seems to be a long list! I need to create a client in the other provider and add it's ID/secret/URL to Cognito, that works. I used the same client ID/secret to generate my bearer token. But when I'm in client creds flow in Cognito, I need to set a custom scope. Do I need to add that scope to my initial request to the other provider (The API GW doesn't require a scope, it is just a mock endpoint at the moment in testing). The client_id= in the request is for the client in the other provider, not the Cognito client ID. Should I set it to the Cognito client ID?)
OR do I need to write a custom authenticator for the API GW to validate the token? (Decode JWT, Check : issuer is allowed and signature is valid.)
And not use Cognito at all for these other users.
(If it was an HTTP API, I think I can create a JWT authoriser and it does it all for me, but it isn't and there are some features on REST APIs not available on HTTP (like WAF))
Sorry it's a bit short on details. I could spend days copy/pasting all the configs from ID provider/Cognito but if it fundamentally won't work I wasted my time!
(After trying it, I think maybe federation only works for actual users with a browser based login flow, not clients with a CLI flow. I can't find anyone saying client credentials flow does work anyway!)
Cognito is using the authorization server role. So in all cases, the tokens returned to client applications will be issued by Cognito. These apps will never deal with Azure AD tokens. Multiple types of client can coexist together:
CLIENT CREDENTIALS GRANT
Clients who use this flow might represent B2B connections. The business partner must always get Cognito tokens directly, and no federation is used here.
AUTHORIZATION CODE GRANT
Browser clients will use this flow, and you can configure Cognito to implement authentication by making a second OIDC Connect redirect to Azure AD.
My blog post provides a walkthrough on how settings are configured. Cognito will act as a client of Azure AD and use a scope such as openid profile email.
After a user login, Cognito will receive Azure AD tokens, validate them, then issue its own tokens. Nothing will change in the API gateway, which will continue to verify Cognito tokens.
I checked the minio guide to connect to the identity openid, finally I connected to the minio console window by Keycloak service users, but I failed to use the same username and password in the api and execute the show bucket request through postman.
Is there a way to define a user's openid and allow access to all minio features for that user?
I tried to fix the problem with different openid services like Okta, KeyCloak, Google, but I didn't succeed.
You first need to get temporary tokens after the OpenID handshake for your users, once you have the STS (session tokens) you can use them to make S3 API calls.
https://github.com/minio/minio/tree/master/docs/sts read here on how to do it programmatically
Edit: More detailed documentation is available now at https://min.io/docs/minio/linux/administration/identity-access-management.html
I am using AWS Cognito for authentication in my application. Cognito provides fully client-side authentication. But, we need to store credentials in .env file which is accessible from the browser.
Is it secure to use AWS Cognito for authentication, if I am building an enterprise application and security is important for me?
For AWS cognito the authentication happens at server side. Not on the client side. At the client side we are creating the opportunity for the user to log via his credentials, then the credentials will be sent to AWS Cognito for authentication. Which results in a accept or reject.
Cognito itself is a service that you can build a secure identity foundation on - but not in the way you're proposing it.
Storing static credentials to 3rd party APIs in something that can be easily accessed by (un)authenticated users is a terrible security practice.
The security of Cognito is not your biggest problem, my advice would be to first find a better solution for your static credentials. Sometimes static credentials like API keys can't be avoided, but you should never expose them to your end users. Store them in something like the AWS Secrets Manager or the Systems Manager Parameter Store and retrieve them when you need them. Only store them in memory if possible and never send them to your clients.
What's the best way to check if a user is authenticated, and pull her identity & roles for authorization decisions, via AWS cognito within a JAX-RS WebService environment?
I am thinking about the following architecture on AWS:
Server Side: Java EE backend REST-ful services, which requiring authenticated access
Client Side: A variety of apps (mobile / webapps / etc) that consume the services via HTTP
Not wanting to reinvent security, I am thinking about how to integrate AWS Cognito with the JavaEE backend. I am used to Keycloak which provides an AuthAdapter via ServletFilter handling all the integration with the OAuth2 Token Endpoint and leaving me as a developer to work with Java Security Mechanisms.
Can we integrate AWS cognito to authenticate API calls to our back-end? I was planning to use cognito access token which would be given to a reverse proxy server to create a JWT by value for back-end micro services. But I could not find any method to check the AWS token for validity. Any suggestions?
Thanks :)
Amazon Cognito was not designed to secure developer built APIs and I would caution you from using only the Amazon Cognito token to secure your API.
That being said, the vended Amazon Cognito token is a normal JWT signed using asymmetric encryption. This thread on the AWS forums has some example code in C# that another customer was able to use to verify the token.
Update 2015-07-09 AWS has announced Amazon API Gateway. Using API Gateway you can build a REST interface to your existing API (or to AWS Lamdba functions) secured with credentials retrieved via an Amazon Cognito authflow. See this blog post for additional announcement details.
You can retrieve the JWT tokens after authenticating users using Cognito. Pass the Access or ID token (depending on usecase) to your backend app and decode the token using any standard JWT decoder libraries.
Here is an article with sample code for reference explaining the process.